I can see a real benefit in splitting a project into several modules when the ecosystem is getting large and that you can clearly see the system in several logical parts. As for creating a module for model, another one for peristence, another one for controllers, another one for views, etc… I think that doesn’t make sense and makes it difficult to maintain down the road.

Just my two cents.

I am not completely against breaking down projects in modules, but I still think that it’s a dangerous move; it’s expensive to revert! and if you later discover that the current subdivision in modules does no longer serve your purposes, then you have strong resistance against refactoring the project towards a better structure. So I advise to break the project in modules only where there’s a demonstrated *need* to do so.

I agree about the argument about the collegue who breaks the design, but only in the sense that the module structure helps collegues understand the design. Other than that, I think that if a collegue unwittingly breaks my design, it is my fault! I should explain my design better. Design is an act of communication, and the effectiveness of communication is the responsibility of the speaker. When collegues break the design, perhaps it is a sign that the design is not good enough; it does not serve our purposes well enough.

Thanks for sharing your experience. I’m not against modularization! I’m just saying that splitting your modules in separate Java projects does increase complexity.

Modularization is good, but once you split your code across multiple “projects” it becomes more difficult to do large refactorings. You have an incentive to keep your refactoring contained within a project, and lose the gains you might get from refactoring across them.

So I will keep my code in a single project until the time comes when it’s clear I will benefit from a split. It’s a tradeoff between simplicity and flexibility. More flexibility comes at a cost!

The thing about ant scripts, I agree that you risk having a lot of redundancy and cruft in them; yet there’s nothing to stop you from refactoring them and keeping them clean. Build scripts are code, just like your java code, and must be kept clean by refactoring too.

Perhaps when I’ll take the time to learn Maven well I will change my mind. What I’ve seen so far about Maven I don’t like. I’m not crazy about Ant either, but it suits much better my taste and opinions.

Let me take your points one by one:

1. increases complexity a lot,
Never. Project complexity is never increased by dividing source code into different modules. Each module is independently testable, and looking at any module you can immediately recognize clarity and purpose of it. Of course, if you say there are more integration points, yes, there are. But that does not increase complexity.

2. makes integration longer and more difficult,
Same as first point. Integration is not more difficult. It is easier infact. Just use a already well-tested library without working about the details of that module.

3. is an obstacle to the evolution of the design,
How can it be? When a project is modularized, only then design evolves. Monolithic folder structure creates fear in the minds of the programmers to approach the code itself due to perceived complexity.

4. and results in a lot of work being spent on the build system.
Before initiating a project/module, I spend considerable time configuring Maven (but in later versions of Maven this has reduced considerably due to archetype plugin). This I consider a one-time investment. When this is done correctly, all my team mates are able to consistently build the modules effectively.

This sort of things drives people to introduce things like Maven or Ivy in the project, and that brings a lot of additional complexity.

I use Maven. I have been using it since its inception. It does not increase complexity, but reduces it to a great extent. Using standard conventions I am not writing redundant Ant build scripts these days.

With multiple projects it happens that you do work in one project, and the other projects don’t “see” your latest modifications.

This is never the case if we are managing projects using Maven. We define a parent project with all the sub-modules inside it. Parent changes are always available to the developers.

buildall.sh :
cd project1
ant
cp project1/dist/project1.jar project2/lib
cd project 2
ant
cp project2/dist/project2.jar project3/lib
….

very simple, very clear.

“But i cannot run sh in my windows pc!”
First solution: no windows at all
Second solution: cygwin

The deepest problem with the whole concept is that it usually degenerates into one “star” team writing the “infrastructure”, or “framework”, or some similar kind of bullshit, for the other less-skilled teams to consume. I work on such a team right now, and I still think that the cheaper way to improve productivity in most companies would be to take all the infrastructure guys out in the open and shoot them.

It takes a nearly non-human amount of humility to do a framework right. Most framework teams seem to just go out on a tangent and produce the kind of dog food that they wouldn’t eat themselves. I’m comfortable with saying that in my 10-years-plus experience, exactly 100% of the company frameworks I’ve witnessed were utter shit. (Yes, again, I was guilty of that kind of crime myself).

No Maven, no cry… NetBeans transparently handles the increased complexity in build files, as all you have to do is to declare that your webapp depends on the model jar and so on and so forth. That also pushes us to consider design more properly, much more than having to rely on the way we deal with packages.