Client/server project structure, folder structure, build files, etc.

Question

I'm writing a client and server application. Right now I've just been developing it on my own, so I have written it as one Eclipse project, organized into Java packages (org.myorg.server, org.myorg.client, org.myorg.networksystem, etc.). The project deploys to a single jar file. Then, the client is an applet, so I simply point the applet code parameter at org.myorg.client.ClientApplet inside the jar file, whereas when I run the server, it's a command line application and I just run:

java -jar MyJar.jar org.myorg.server.ServerApplication

Well, I need to clean up its structure and improve the build process. I also want to separate the jar files, so that an user does not have access to a copy of the server built right into the jar file as it is now.

I want to use a continuous integration server such as CruiseControl. It would be really cool if I only needed to check my code into the SVN repository; then the CruiseControl server would grab the code, compile it and package it into separate jars, then deploy the server jar onto my dedicated server and run it, and also deploy the client jar onto my web server so that the applet is updated.

I can figure out CruiseControl. My current issue is how to separate the code. It's nicely separated into client and server packages, but then there are some shared packages such as the network protocol. Should I separate my project into 3 projects for client, server, and common? Should I do something else? I was considering writing Ant build files by hand, but I would really like to stay in Eclipse.

How can I best organize my code to meet these goals?

(by the way, sorry if this question is confusing, I think I'm having a hard time putting into words all of the different questions swirling around my head)

Answer 1

If seems you already know what you need to do, however, If you want CruiseControl to compile and package the code, then you will need to use a tool like Ant, or possible Maven, Gradle, or some other build tool, in order to have it do what you want. Even if you have a build tool package the code you can still use Eclipse to build and run everything.

I am not sure how familiar you are with Ant, but using Ant will give you more control over the build process at the expense of requiring defining the process. Other tools like Maven and Gradle have a prescribed way of structuring the code that reduces the amount of configuration for a build, and in the case of Maven I am not sure that one can change how it expects the project layout to be. Gradle on the other hand can have its defaults change.

As far as organization, I think separating the code into client, server, and the network protocol shared by the client and server, as you have mentioned, would be good. I don't use Eclipse, so I am not sure how that would be done. You could just package the client and server into separate JARS with the class files from the network protocol module in both, or just make three JARS.

Answer 2

You're on the right track with separating your project into 3 separate projects - you'll need 1 client, 1 server, and 1 common.

You can define inter-project dependencies on each project in Eclipse - if you right click the project, it's in the dialog launched by the "configure build path" option.

You should look into writing ANT files to handle the build though - it will be much easier to plug into CruiseControl later.

Answer 3

I think your question is excellent.
I suggest looking into maven. It's specifically designed to provide common, best-practice workflow, including development, testing and deployment phases. Even if you end up not using maven, it may give you some ideas about projects structure.
Eclipse has great integration with ant, so you can use ant to build/deploy your projects and still stay in Eclipse.
I definitely suggest separating your code into several Eclipse projects. This would enforce the correct dependencies: you can make sure that your client code may use your common code, and your server code may use your common code, but the common code can't use any of the other two, and similarly the server can't use the client code.

Answer 4

For large projects, it would be better to have separate Eclipse projects for each of client, server and common.

However, that would be overkill, in my opinion, for a small project: in such a case I would keep it as one Eclipse project, but write custom Ant targets (all in the same build.xml file) to handle the packaging of the client vs the server jars. Common code would simply appear in both jars.

But yes, you would have to do some manual Ant work, but that's a good skill to have anyway.