maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <>
Subject Re: custom maven plugin default phase
Date Sat, 20 Feb 2010 16:22:19 GMT

On Feb 20, 2010, at 10:56 AM, tbee wrote:

> jvanzyl wrote:
>> Most people we deal don't actually find that, it's usually not understand
>> the tool and the impatient find it easier to roll their own solution.
> During my research I found many developers of well know open source projects
> tried and failed migrating to Maven.

As we have generally stated, and in almost all cases winds up being true, that using Maven
your first time in conjunction with a conversion usually ends up in failure. Why? Because
you are trying to convert all the baggage you have to a model that doesn't allow it. You find
people that that complain all the time like Howard Lewis Ship and that Maven is a failure
and that he's going to try Ivy, Gradle, Buildr or whatever else. But what is he using to build?
Maven. What do his users ask him to use? Maven. Where do users want the artifacts? In a Maven

> After all that is why Ivy came to be,
> and Gradle and all the other Maven derivates.

It's more a matter of this first reason. People want to do whatever they want and Maven simply
doesn't allow that. The second reason is some shoddy plugins, and that's certainly true in
some cases. But the Maven project can't control how every Maven plugin is constructed. Ivy
decided to re-implement an artifact resolution system instead of using Maven's which was already
separated. In the end Ivy is not used that much which we see from Maven Central traffic, and
no one uses Ivy repositories. So yes, it was create but for the wrong reasons IMO. Grade is
in the same vein except XML is additionally anathema. If these systems had even a 10th of
the users of the system as Maven does all sorts of problems would be exposed.

> If there is smoke, then there
> is a fire. It can't be that all these developers are too impatient.

We happen to have lots of happy users as well. And even the biggest whiners are using Maven
in some way shape or form. Look at Grails: what are they working on presumably because it's
highly requested by the users? Maven dependency mechanisms and interactions with Maven repositories.

> Hell,
> I'm on this migration thing for about 3 months now.

Then that right there is your problem. Is this your first time using Maven seriously? Then
you've made the same serious mistake we tell everyone not to do.

> Maven simply is fairly
> complex; I'm busy migrating our medium sized projects and after three months
> I'm still fine tuning. And my first attempt at a custom plugin immediately
> runs into difficulties immediatly.

Building software gets complicated. Anyone who tells otherwise doesn't build much software.

> One observation; in ANT I tell my build system how to go from A to Z.

So do you choose procedural programming languages as well?

> If I
> look at my pom file, I do not see the "A to Z" , but I see almost every step
> configured. I see A, libraries, because I want a copy for the EDI. I see B,
> compiling, because I have to specify the source version, etc. So even though
> the build script does not contain the exact sequence, it in core pom.xml
> contains the same information as build.xml.

There's abstraction in Maven. There are plugins (like the effective pom) and IDE tooling to
help with some of this.

Again, if you are doing a one off build then who cares. It doesn't much matter and you might
as well write out a literal, procedural build script. Maven is no gain for you.

> The Maven concept is good, don't misunderstand me, but at the moment it is
> too much EJB2 and not enough EJB3, as a metaphore.

Whatever, that metaphor is completely lame. Most of time it's people who haven't taken the
time to read the books, work on a Maven project prior to doing a conversion or just expecting
Maven to be an Ant build with some dependency management capabilities. That's just not the
way Maven works.

> If you guys are able to
> do two things for Maven 3:
> - make it easy to extend or override behavior, add easy plugins including
> default behavior (looping back to the origin of this thread)

This is not overly hard. What you're asking to do is not that difficult.

> - make the configuration more compact

Again, if you have any experience writing plugins or looking at existing plugins you see that
the goal is to eliminate the configuration almost entirely. If you have a plugin that specifies
defaults and write the plugin to operate primarily on the existence of resources and behave
accordingly then you can arrive at no configuration most of the time.

> Then things should be quite different.

Not really. I think we'll always have people like you who start out with the wrong expectations.
Starting out the projects like conversions on the wrong path, expecting the system to be fully
scriptable (which only leads to long term disaster and this is based on a lot of experience),
or just thinking they aren't going to have to read anything and they will just figure it out.

If after all that, it doesn't work for you then don't use it.

But Maven use doubled last year, so usage it going up not down. And people don't use systems
if they deliver no value which is why this project continues to prosper.

> jvanzyl wrote:
>> So you can either help fix the lacking implementation, or roll something
>> no one else in the world is going to understand. 
> You make a compelling point. But considering the knowledge gap between you,
> the developers of Maven, and me, that is too idealistic. I simply do not
> pretend to have the knowledge to make enterprise level design decisions on
> this. My projects are medium in size. But if you guys can make a good rack,
> then I most certainly can put the jackets on.
> Can I try the Maven 3 features already?
> -- 
> View this message in context:
> Sent from the Maven Developers mailing list archive at
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:



Jason van Zyl
Founder,  Apache Maven

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message