maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tbee <>
Subject Re: custom maven plugin default phase
Date Sat, 20 Feb 2010 06:51:58 GMT

jvanzyl wrote:
> Sure, if you're dealing with a single module there's no benefit of
> inheritance. If you really find you want goals of certain plugins to be
> executed automatically then yes, you make a custom packaging and make it
> transparent by referring to the packaging. This is all with Maven 2.x.
> With Maven 3.x this will be easier with mixins and we can learn from our
> experiences with Maven 2.x.

The reason why I'm back at Maven, is 3.0. I made a round trip in the last
few months; we have Ant, so I started with Maven 2, then fell back on Ivy,
really made an effort with Gradle (but it was lacking in documentation) and
after a few other tools I examined, I'm back at Maven 3.0. This time I
included setting up a Nexus repository to get the "whole experience".

Unfortunately I'm not experiencing much difference between 2.0 and 3.0; I
tried to use to Groovy style, because it combines easy custom actions with
the standard phases, but there is no documentation (yet) on how to invoke
maven. So I went for the basic pom.xml, but run in the same issues that I
would have with 2.0. 

All in all Maven 2 is simply too complex; there is enough feedback on that
by people with higher profiles than me, so no need to add. Concept is good,
implementation is lacking.

jvanzyl wrote:
> Most of us are aware of the problems you're facing and we'll fix a lot of
> that with Maven 3.x. But in the meantime we can't radically change things
> without harming a lot of users. Maven 3.x is almost 100% backward
> compatible but will allow users to try out new features incrementally
> (that is a lot harder then it sounds). 

I understand completely. I had a pretty large piece of text here, but let's
summarize that with the statement that I totally agree with Kirill (author
of the Substance look and feel) on this point: on any major version release
you have to restructure so that the new version matches what is believed to
be the best implementation of the problem at that time, even if this means
breaking API compatibility. But there is nothing wrong with shipping a 2.0
parser that mimicks the 2.0 onto the 3.0 API.

At the moment, after trying all these build systems intensly, I'm wondering
if I need to introduce MAVANT; maven build cycle where ANT tasks are
attached to the phases, using Ivy for reference resolving. But that sounds
an awful lot like Gradle.

First see what Maven 3 will bring. Is there any documentation aside the
teaser articles, on how to use the new features?
View this message in context:
Sent from the Maven Developers mailing list archive at

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message