I may be missing something here...
[ SNIP ]
Step back for a moment. We are talking servers and their clients. On the
server side you start out with a vanilla install on a physical box or
VM: might be Apache httpd or IIS, might be Tomcat or WebLogic, might be
ActiveMQ or WebSphere MQ, might be Active Directory or OpenLDAP, might
be H2 or DB2 or Oracle or SQL Server...you get the idea.
The server install sets up directories, executables (services or tools),
libraries (DLLs, *.so's, Java JARs etc), baseline config information,
and so forth. At this stage of the game you may or may not have a
useable, albeit uninteresting, server. Further configuration is often
required to make it useable (e.g. the directory servers).
After all this it's probably still uninteresting. You need to write
server applications, and you need to develop clients (often, not
always). For a web server or app server you write your ASP.NET MVC or
Java EE or PHP apps. Those apps will use libraries that came with the
baseline server, but you may use other libraries that are either shared
on the server or bundled up/deployed with the specific server app.
In some cases the actual server that you write your own server
applications on is *itself* a server application sitting on a server.
For example, ECM systems like FileNet P8 or Alfresco are actually
humongo web apps (more or less) on app servers like Tomcat or WebSphere
(plus using database servers and maybe directory servers) that you can
the drop your own apps onto. IBM Cognos is itself a Java EE app.
On the client side, if it's a web app you've got a browser; there's not
anything left to do. But possibly your server application is providing
SOAP or REST web services - in that case you will be writing client
code. If CORBA, you're generating and writing client code. If WebSphere
MQ you're often writing client code.
These clients also need libraries, whether JARs or native shared/static
libraries. Frequently there are client installers that supply all of this.
You do not generally copy things in the manner you describe. Server
installs can be pretty complicated - if you need a new server on a new
box then you work through the approved install process...just like you'd
do with an .EXE or .MSI installer for a standalone app on Windows.
In fact, with few exceptions, *removing* a server and all its artifacts
can be pretty complicated and tedious too.
As to deployment of server and client apps, these often have a
deployable form. In Java EE these are JARs or WARs or EARs. Other
systems (ESBs, BPM systems, certain forms of IIS app deployment etc)
often have a publishing/deployment procedure that involves ZIPs of
directory/file structures. The IDE that you develop in, more often than
not, already knows how to create the proper deployment packages.
As for Java SE versus Java EE, the latter is the former plus reams of
extra libraries. The latter also encompasses the contracts for anyone
who is going to provide a Java EE-compliant application server.