When to create multiple projects in Eclipse?

Question

I'm often wary of creating multiple projects in Eclipse. Let's take a scenario:

• There is a main J2EE project, which has all the business logic, render GUI etc
• Then there is one more supporting project, which basically has only the Hibernate POJO and Hibernate related configuration stuff

This means the Hibernate project jar will need to be placed in the main project to test it, every time there is a change.

What are the disadvantages?

• Smallest of change in the class, you need to build the jar all over again and transfer to the server
• You can't directly only transfer the class files, you have to build the complete jar again
• In remote debug mode, edits will not hot replace the class files from Hibernate project, big pain to transfer jar and restart server all the time

What are the advantages?

• If I had to split my J2EE project into 2 project to separate concern tomorrow, I can directly copy the DB part, i.e Hibernate jar and start using split projects

So now my question:

• Is there a guide line on when to to create a new project instead of a new package?
• In the cases like above, would it be a good idea to merge both in one project to resolve 3 disadvantages and contain one advantage?
• What is the industry standard? Best practice?

Answer 1

The more you can separate your projects, the better.

As soon as you can establish a clear dependency separation, move it out into its own project. As it grows, this will enable you to reuse code easier in other projects.

Answer 2

In your case, if you have different layers, it's avisable to put the layers in different projects. This gives a little extra motivation to keep the layers separat, talk through interfaces and avoid circualar dependencies between layers (projects can't depend on each other!)

I often introduce one specialized project that contains all libraries and resources for the entire application. Maybe another one that is only used to build and deploy the application (the ant/maven build scripts, the product definition in case of RCP applications). And finally, think about defining all test cases in separate projects. Test sometimes need special libraries and resource files (logger configs, database dumps with test data) and those files shouldn't mix up with the applications config files and libs.