Package vs project separation in java

Question

First off, I'm coming (back) to Java from C#, so apologies if my terminology or philosophy doesn't quite line up.

Here's the background: we've got a growing collection of internal support tools written for the web. They use HTML5/AJAX/other buzzwords for the frontend and Java for the backend. These tools utilize a lightweight in-house framework so they can share an administrative interface for security and other configuration. Each tool has been written by a separate author and I expect that trend to continue, so I'd like to make it easy for future authors to stay "standardized" on the third-party libraries that we've already decided to use for things like DI, unit testing, ORM, etc.

Our package naming currently looks like this:

• com.ourcompany.tools.framework
• com.ourcompany.tools.apps.app1name
• com.ourcompany.tools.apps.app2name

...and so on.

So here's my question: should each of these apps (and the framework) be treated as a separate project for purposes of Maven setup, Eclipse, etc?

We could have lots of apps appear here over time, so it seems like separation would keep dependencies cleaner and let someone jump in on a single tool more easily. On the other hand, (1) maybe "splitting" deeper portions of a package structure over multiple projects is a code smell and (2) keeping them combined would make tool writers more inclined to use third-party libraries already in place for the other tools.

FWIW, my initial instinct is to separate them.

What say you, Java gurus?

Answer 1

I would absolutely separate them. For the purposes of Maven, make sure each app/project has the appropriate dependencies to the framework/apps so you don't have to build everything when you just want to build a single app.

Answer 2

I keep my projects separated out, but use a parent pom for including all of the dependencies and other common properties. Individual tools / projects have a name and a reference to the parent project, and any project-specific dependencies, if any. This works for helping to keep to common libraries and dependencies, since the common ones are already all configured, but allows me to focus on the specific portion of the codebase that I need to work with.

Answer 3

I'd definitely separate these kind of things out into separate projects.

You should use Maven to handle the dependencies / build process automatically (both for your own internal shared libraries and third party dependencies). There won't be any issue having multiple applications reference the same shared libraries - you can even keep multiple versions around if you need to.

Couple of bonuses from this approach:

• This forces you to think carefully about your API design for the shared projects which will be a good thing in the long run.
• It will probably also give you about the right granularity for source code control - ie your developers can check out and work on specific applications or backend modules individually

Answer 4

If there is a section of a project that is likely to be used on more than one project it makes sense to pull that out. It will make it a little cleaner as well if you need to update the code in one of the commonly used projects.

Answer 5

If you keep them together you will have fewer obstacles developing, building and deploying your tools.

We had the opposite situation, having many separate projects. After merging them into one project tree we are much more productive and this is more important to us than whatever conventions happen to be trending.