[jboss-dev] Why Maven sucks (part 1)

Carlo de Wolf cdewolf at redhat.com
Mon Apr 21 06:23:34 EDT 2008


This is going to be a long post, so grab a cup of coffee.

Let me start with the fact that I'm biased against Maven and before any 
Maven hater starts cheering, don't. I still think we should use Maven to 
it's full advantage (whatever that may be).

I don't think calling Maven an abomination and a piece of crap is not a 
valid reason to ditch it. We need to form a well informed opinion on it.

Let's start with the goal of Maven and how we apply it.

"Maven is a software project management and comprehension tool. [...] 
Maven can manage a project's build, reporting and documentation from a 
central piece of information."

Our application of Maven is just to use it for dependency management. So 
the complete Maven scope extends well beyond our requirements. This is 
all fine if the requirement is properly met and if the tool limits 
itself to that scope.

Problem 1 then appears: Maven is 'opinionated software'. In other words 
convention is prioritized over configuration. Given that Maven goes 
beyond scope and thus start mandating certain conventions outside the 
'dependency management' area it starts to suck. I want be in control of 
the build process and Maven to do dependencies. (We've attained that 
goal in AS build, so we're stopping there.) But now we get a declarative 
build process in which I have to describe my project and press a 'I'm 
Feeling Lucky' button to see the result.

On to the second problem: the implementation of dependency management in 
Maven. It looks fine on paper, but again it has a notion of being 
'opinionated' and thus you're not in control. The version of 
dependencies you specify in the pom.xml are advisements (WTF!). In 
actuality Maven picks a semi random (okay I'm exaggerating a bit) 
version instead of informing you that you're an idiot for mixing bad 
stuff. Version ranges might help in this area by being more than just 
advisements.

Now if it was a tool focussed on dependency management (like Ivy) it 
would have solved the real problem: snapshots. So let's do an example:
- as trunk -> ejb3-core-0.1-SNAPSHOT -> 
ejb3-interceptors-0.13-0-SNAPSHOT -> aop-2.1-SNAPSHOT (for the example)
If I happen to deploy a new snapshot of aop, it'll break AS build. Why: 
ejb3-core is not compatible and Maven blindly loads it up. This is not 
possible in Ivy, it's snapshot repository looks like:
- as trunk -> ejb3-core-0.1-20080421 -> 
ejb3-interceptors-0.13.0-20080421 -> aop-2.1-20080420.
If I happen to deploy a new snapshot of aop you get and I run a nightly 
build on ejb3 you get:
- as trunk -> ejb3-core-0.1-20080421 -> 
ejb3-interceptors-0.13.0-20080421 -> aop-2.1-20080420
- ejb3-interceptors-0.13-0-20080422 -> aop-2.1-20080422
Since ejb3-core didn't properly build there is no new snapshot for it 
and AS build is unaffected.
Combine this with unit tests and you got a pretty stable setup.

So at the end of the day we're not yet there with Maven:
1. It has crummy implementation of snapshots that needs to be fixed;
2. It must have proper conflict resolution;

So let's first make JBoss a shining example of how to do a mega project 
with Maven. After that we can really do a well informed 'Why Maven sucks 
(part 2)'.

Carlo




More information about the jboss-development mailing list