Why use many sub-projects and dependencies over packages?

Question

I’ve mostly in my career worked in small or mid-sized java projects. I recently saw a huge project comprising of 30 projects in eclipse. I don’t really get concept of creating many small projects and then maintain inter-project dependencies. When do we prefer this over simply organizing stuff in packages?

I guessed it’s a maven thing (have mostly been using Ant). I’ve been reading up on Maven’s concept of modules as well – I saw some links on net recommending creation of different modules for web, dao and service layers under a parent module. Is it really a common/best practice?

With or without maven – does such division really makes life easier? Isn’t it more compact to have everything in a single project with well-defined packages structure for different layers?

Answer 1

It's common to split up projects into API, implementation, web, etc. components–when there's a need to do so. Large projects are just that: large.

There are benefits to keeping components separate"

• Re-use functionality (e.g., the web layer uses the service layer
• Package individual components (e.g., ship jus the API to a client)
• Version sub-components; define their version dependencies

You can do all the same stuff with one giant project, but it's more difficult to determine what goes where, and why. Life is easier when those lines of demarcation are clearly defined.

How much easier depends on the project, but when you're dealing with hundreds of thousands of lines of code, occasionally millions, breaking that stuff up saves huge headaches.

Answer 2

Why choose to create a separate module in maven? To help you with your development. There really is no other reason.

The are a number of different reasons why you may want to create a separate module:

1. Separation of concerns: yes, you can do this with packages, but if it's in a separate module, then it can be compiled separately, and you can reduce the amount of tangle[*] in your packages.
2. The modules are managed by different teams, with release cycles of their own.
3. More understandable code: If all of your dao code is in one module, and all of your web in another, you can test them separately.
4. A module can be a separate deployable entity. I have a project which has two web apps, 5 batches and two other core modules (one core for the webapp and one core for the batches). I can now build and deploy each module separately.
5. The modules are published and used externally. If this is true, then you want the minimum amount of 'other' code in this module.

You choose to break up into modules for the same reasons as you would for separating into packages, but at a higher level, at a group of packages.

30 does seem excessive. But there may be good reasons for it. It's up to you and your project to decide what is the right level for the number of modules.

Personally, I try not to split excessively, unless there is a very good reason to do so.

[*] Tangle: mess which describes the links between packages. Package A uses B, which uses C, which uses both A and B. Something which doesn't help understanding.