How to organize larger Java projects - Projects vs. Namespacing?

I'm wondering if there is some recommended reading, best practice or opinion on how to organize larger Java projects.

I made the observations that there are folks who split up everything into projects (i.e. modules) and create many many projects that sha开发者_如何学JAVAre a web of dependencies. This has the advantage that compilation is often super fast, but when the project gets large nobody knows anymore what depends on what and why. Not talking about dependent libraries, version conflicts & co.

The alternative is to have just a couple of projects such as frontend, backend, ... . The namespacing does the job.

Any opinion, further reading anyone could recommend?

As soon as you start splitting a big project up into smaller projects, you encounter a lot of dependency tracking that you generally didn't have to consider. You could manage this yourself or you could use software which already handles a lot of the core issues.

I would recommend Apache's Ivy. It integrates well with Apache's Ant, and has a separate configuration file (which gets checked in) to track what is required for each kind of build.

Apache's Maven is another good choice; however, it does a lot more than Apache's Ivy. Sometimes that "a lot more" means you doing less of what you would have done anyway, sometimes that "a lot more" means you are doing (and configuring) things that you didn't do before. Depending on the fit of your practice to Maven's, migrating to Maven might be easy or very hard.

In addition, using Ivy, you can set up your own private repository of "permitted" jar files to pull from, and that will make code auditing much easier. Basically, reconfigure ivy to not pull from the web, but to pull from your local repository only, and then control access to the repository to only allow jar files which were reviewed to have acceptable licensing.

Once you have software in place, you can afford to split projects up into smaller pieces. This will permit you to do the right thing (if your project favors small decomposition) instead of the expedient thing (a few big chunks which might not really buy you much in decomposition maintainability). As far as where to make the cuts, that depends heavily on the specifics of your application.

Many small pieces tend to be easier for a new person to digest one-by-one. They also get people thinking about where functionality is to be added to a project; however, it does cost time and effort to untangle and separate all of the components. The plus side is that it is generally easier to test and validate something smaller, the downside is that it is a longer road to decompose one monolithic collection of responsibilities into many small, well integrated yet functionally disparate units.

Good luck

A very large project will need to have some way of tracking all of the libraries and other dependencies that it uses. The defacto standard for doing this is Maven. It's definitely the best way to start keeping track of what is going into your application.

Then you can decide how to split your application up. Basically, what you're trying to do here is to split up your application up into complete functional pieces. For instance, if you had a website that had a contact form, a photo gallery, a shopping cart, and a forum, you would split the project up into pieces that contained each of those different modules.

Actually, you will want to utilize both projects and namespacing.

Namespacing is an important tool for differentiating what purpose a code has at the code level. Regardless of what project a class comes from, the package should give me some idea of its purpose.

At a higher level, it is easier to manage builds and your development environment by having your code separated into projects. For instance, if you are developing a UI, why do you need to have the database code loaded into you IDE? It is just extra clutter in your workspace. It also makes it simpler to share common functionality between different projects. This will of course lead to needing some form of dependency management, of which either of the mentioned tools such as Maven or Ivy will suffice.

An important note though. Do not use split packages between projects. This causes nightmares if you or anyone who will ever use your code wants to do so in an OSGi environment. So, your namespaces should be unique within a project, although they should share a common root with other related projects.