I have a Java project that has both server and client packages. In addition I have a library package.
I use eclipse and have put everything in a single Java proje
... the problem is that when I export, everything gets added to the Jar file.
Is that really a problem? Maybe the shared code is an asset rather than a liability. Perhaps you should optimize the developer issues before worrying about the deployment problems that, around here, we've decided aren't problems after all.
So I suppose I need two different projects, client and server, but what about the shared library files? What do I do about them? Do I actually need three different projects? It will become a little unwieldy as everything is actually related and I would like to keep them together.
We have a similar situation here and chose to embrace the shared code. Everyone gets the same code and choses what mode and configuration they need to start up.
If you check out our large-ish system (a bit over 5000 classes), you get the code for the servers (two main flavors), the clients (another two types), shared content (third party jars, visual assets, etc.) and site specific material (configuration files, start-up scripts and example data).
The result is that, after one checkout, you have the complete package for all of our primary locations, build scripts and Netbeans and Eclipse launch configs. As a result, you can go from an empty machine (with just an IDE) to a working client-server combination in about five minutes.
As a result, double-click the server icon and you launch a server process, running the site-specific configuration. Double-click the client and you launch a client process that's ready to connect to the server you just made.
Punchline: don't make development and deployment harder on yourself unless there's a very good reason. In our case, it was simpler, cheaper and easier to maintain the situation where we gave every installation the exact same package.