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

[Max Rydahl Andersen]

Damn, a long thread and I never thought I would be the one pointing to a solution 
for many of these issues.

Did anyone look into the enforcer plugin for Maven ?
http://maven.apache.org/plugins/maven-enforcer-plugin/

This is what #maven on irc pointed me too when I bitched about being able to 
stop a release from happening if I used any snapshot versions.

The builtin rule for "noSnapshots" is described here: http://maven.apache.org/plugins/maven-enforcer-plugin/rules/noSnapshots.html

I think it would be worth checking out.

/max

> 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
>
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>