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 03:29:58 GMT

On Feb 19, 2010, at 1:29 PM, tbee wrote:

> Stephen Connolly-2 wrote:
>> what maven gives you is a consistent set of phases that any developer only
>> has to learn once.
> Agree and that is the lure of Maven. But if you look at the plugins,
> execution tags and the weird behavior of per default compiling against java
> 1.3 (in stead of the default of the used JDK, which mean you always have to
> add these tags), noone can really claim that a Maven pom is much more
> readable than a well setup ant file. 
> I agree; "well setup" is important here, but at least it is possible to do
> it clean and concise. Coming back to my question in this thread; adding a
> new plugin to the build cycle requires (in best standard syntax) at least 5
> lines of code, and that is without any configuration. Why can't I just
> specify in the plugin when it needs to run, so I only need to add it?

Because a plugin consists of many goals and Maven doesn't know which goal in your plugin you
might want to run. Typically you would configure this in a parent POM with the goals you want
to run, and then configure any child modules with only the configuration you wish to apply.

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.

Most users don't find defining the pluginManagement section to setup all the plugins they
are going to execute not over onerous. Even in an Ant macrodef you're going to have to define
the skeletal structure of what you want to execute to reuse later. Most don't honestly care
if it takes 5 lines to invoke. I've asked thousands of people at this point. Not that it won't
stop us from making something more terse. 

> I like the idea of Maven, but in the implementation it is often missing the
> point. Another example: take a pom-package (a pom file with just references
> but no artifact on its own); if you refer to that pom, you need to specify
> type=pom in the reference. Why? Maven can read the referred pom file and
> come to that conclusion itself.

Because how the classpath is constructed by referring to the type. Each type carries with
it instructions, the default is jar which is why it's not present most of the time. There
are handlers that are used in conjunction with a type which controls how that particular type
is dealt with in Maven. Handling BOMs will be better in Maven.

> Anyhow, this small rant naturally is not focused on you, I'm just expressing
> my amazement about that the answer is not what I expected.

Generally the case when you first you Maven, and you are accustom to whacking together a macrodef
in whatever form seems natural to you. We deal with millions of users trying to do the same
things the same way. We've made some mistakes, for sure, and we can't just change things immediately
without breaking things. 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). Sure, if you
make your Ant build you can do whatever you want, it only affects you. We have a slightly
larger set of users to worry about.

> Thanks for answering though!
> -- 
> 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