maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Bentmann <>
Subject Re: Default plugin execution id
Date Sun, 09 Nov 2008 11:05:24 GMT
Christian Schulte wrote:

> Not having specified an execution id does not necessarily mean someone
> did not care about it. It means someone explicitly referred to the
> default execution.

I disagree with this interpretation, mainly because I am not aware of 
any docs that would indicate this to the user.

The "Maven Model" [0] and the corresponding XSD [1] say about the 
execution id:

> The identifier of this execution for labelling the goals during the build, and for matching
executions to merge during inheritance.

This description does not mention that the id "default" is meant to 
refer to executions provided by lifecycle mappings from a packaging type.

The "POM Reference" [2] likewise does not state that there are special 
ids available to refer to default executions. And from the "Introduction 
to the Build Lifecycle" [3]:

> Separate executions can also be given an ID so that during inheritance or the application
of profiles you can control whether goal configuration is merged or turned into an additional

This expresses the id's purpose to assist in
a) inheritance and
b) profile injection
Again, it's not stated that it can be used to control the executions 
provided by a packaging type. In particular, the phrase "executions 
*can* [...] be given an ID" merely expresses the ID is optional, not 
that omitting it refers to the default executions of a plugin.

> That is not working in Maven 2.0.x and that's the bug
> to fix.  A POM which relies on that bug needs to get fixed.

Considering the references I gave above, IMHO this is a design weakness, 
not a bug. This hairsplitting is not because I want to simply reduce our 
bug stats but because there is a subtle difference with regard to a 
user's expectations. Spoken laxly, a bug is "should work as per spec but 
actually doesn't" while here we have "would be nice to work but 
currently isn't supported".

Hence, I don't see a foundation to require users that currently omit the 
execution ids to "fix" their "broken" POMs because we retrospectively 
changed the semantics. Choosing a fresh identifier as suggested by 
others before instead of "default" is less likely to break existing builds.



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

View raw message