You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Nick Pellow <np...@atlassian.com> on 2008/12/04 02:29:15 UTC
What will replace the @aggregator MOJO configuration?
Hi,
I noticed that the 'aggregator' parameter for a MOJO is slated for
deprecation in a future release of Maven.
http://books.sonatype.com/maven-book/reference/writing-plugins.html#d0e22494
What should be used instead, to fulfill the following use-case:
- a multi-module project, which would like to assert something about
the entire project at the very end of the build.
A concrete example is mentioned on our Clover Forums at http://forums.atlassian.com/post!reply.jspa?messageID=257294857
.
The user would like to only run clover2:check on the entire project,
not on each sub-module.
Cheers,
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What will replace the @aggregator MOJO configuration?
Posted by Nick Pellow <np...@atlassian.com>.
> being able to bind to the front and back of a lifecycle would be
> absolutely
> splendid
>
+1. A simple event system which fired build events to registered
listeners (plugins could register these) would go a long way. Example
events could be:
* Build Started
* Phase Started
* Goal Started
* Goal Ended
* Phase Ended
* Build Failed
* Build Complete
>
> Brian E Fox wrote:
>>
>> Yes it's binding the aggregator with @execute to a lifecycle that
>> is the
>> problem. There's nothing wrong with aggregators that are meant to
>> perform
>> some action from the CLI. The trouble is that everyone ends up
>> making two
>> goals, one @aggregator and one xxx-only goal that is without the
>> aggregator.
>> I know of too many instances where someone bound an aggregator
>> executor
>> goal
>> to a lifecycle and ended up with n*n-1 recursive builds or other
>> crazy
>> behavior.
>>
>> What I think we need is an annotation that says "execute up to this
>> phase
>> only if it hasn't already run" essentially a minimum phase execution.
>>
>> There also needs to be a way to attach a plugin to execute before the
>> lifecycle to influence things like inject dependencies and we also
>> need a
>> way to bind to the very end of a build for cleanup or metric
>> collection
>> types of things.
>>
>> On 12/5/08 7:59 PM, "Brett Porter" <br...@apache.org> wrote:
>>
>>> On 06/12/2008, at 9:37 AM, Brian Fox wrote:
>>>
>>>> There's nothing presumptive about the fact that it HAS been
>>>> deprecated in trunk for quite some time now. (since it was still
>>>> called 2.1-snap)
>>>
>>> Ok, you're right, when binding to the lifecycle (which admittedly we
>>> are talking about here), though not generally.
>>>
>>> Aren't the source of these problems when it is used in conjunction
>>> with @execute? (Which is probably the more problematic annotation, I
>>> was never happy with the way that was done).
>>>
>>>>
>>>>
>>>> The aggregator is full of problems and usually leads to recursive
>>>> builds when you bind it to the lifecycle. A complely new concept is
>>>> needed to handle this use case.
>>>
>>> But doesn't yet exist, so perhaps a warning is more appropriate
>>> than a
>>> deprecation at this point. It does still work for the limited use
>>> cases it was designed for (such as the Nick is referring to).
>>>
>>> Cheers,
>>> Brett
>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/What-will-replace-the-%40aggregator-MOJO-configuration--tp20825520p20873221.html
> Sent from the Maven Developers mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What will replace the @aggregator MOJO configuration?
Posted by jallen <jo...@hotmail.com>.
being able to bind to the front and back of a lifecycle would be absolutely
splendid
Brian E Fox wrote:
>
> Yes it's binding the aggregator with @execute to a lifecycle that is the
> problem. There's nothing wrong with aggregators that are meant to perform
> some action from the CLI. The trouble is that everyone ends up making two
> goals, one @aggregator and one xxx-only goal that is without the
> aggregator.
> I know of too many instances where someone bound an aggregator executor
> goal
> to a lifecycle and ended up with n*n-1 recursive builds or other crazy
> behavior.
>
> What I think we need is an annotation that says "execute up to this phase
> only if it hasn't already run" essentially a minimum phase execution.
>
> There also needs to be a way to attach a plugin to execute before the
> lifecycle to influence things like inject dependencies and we also need a
> way to bind to the very end of a build for cleanup or metric collection
> types of things.
>
> On 12/5/08 7:59 PM, "Brett Porter" <br...@apache.org> wrote:
>
>> On 06/12/2008, at 9:37 AM, Brian Fox wrote:
>>
>>> There's nothing presumptive about the fact that it HAS been
>>> deprecated in trunk for quite some time now. (since it was still
>>> called 2.1-snap)
>>
>> Ok, you're right, when binding to the lifecycle (which admittedly we
>> are talking about here), though not generally.
>>
>> Aren't the source of these problems when it is used in conjunction
>> with @execute? (Which is probably the more problematic annotation, I
>> was never happy with the way that was done).
>>
>>>
>>>
>>> The aggregator is full of problems and usually leads to recursive
>>> builds when you bind it to the lifecycle. A complely new concept is
>>> needed to handle this use case.
>>
>> But doesn't yet exist, so perhaps a warning is more appropriate than a
>> deprecation at this point. It does still work for the limited use
>> cases it was designed for (such as the Nick is referring to).
>>
>> Cheers,
>> Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/What-will-replace-the-%40aggregator-MOJO-configuration--tp20825520p20873221.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What will replace the @aggregator MOJO configuration?
Posted by Brett Porter <br...@apache.org>.
I don't believe the doc covered pre-/post- lifecycle operations, just
the @aggregator changes that were the initial discussion.
They'd probably need a new proposal. Perhaps something hooking into
the model builder listening from the new work on trunk (just taking a
wild stab in the dark, haven't looked at it since they were introduced).
- Brett
On 15/12/2008, at 8:11 PM, Stephen Connolly wrote:
> 2008/12/15 Brett Porter <br...@apache.org>
>
>>
>> On 12/12/2008, at 6:57 AM, Barrie Treloar wrote:
>>
>> On Fri, Dec 12, 2008 at 3:51 AM, Brian E. Fox <brianf@reply.infinity.nu
>> >
>>> wrote:
>>>
>>>> I think most of these ideas are already covered in the lifecycle
>>>> proposal out there that john wrote.
>>>>
>>>
>>> Can you paste the link in please?
>>>
>>
>> http://docs.codehaus.org/display/MAVEN/Deterministic+Lifecycle+Planning
>>
>> There are two linked docs at the bottom that are probably more
>> relevant.
>>
>
> It's not clear to me from that proposal, how we could accommodate
> plugins
> that need to update the pom...
>
> For example, I'd like that versions-maven-plugin could work
> preemptively for
> goals like update-parent...
>
> Perhaps some mojos will need a way to run outside the lifecycle, or
> at least
> signal that they could affect build plan determination somewhat... for
> example, if I update the parent of some modules to a newer version,
> that
> newer version may add/remove profiles, add/remove plugins, etc.
>
> Perhaps that is covered in the Wiki, but it's just not clear to me
>
> -Stephen
>
>
>>
>>
>> - Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What will replace the @aggregator MOJO configuration?
Posted by Stephen Connolly <st...@gmail.com>.
2008/12/15 Brett Porter <br...@apache.org>
>
> On 12/12/2008, at 6:57 AM, Barrie Treloar wrote:
>
> On Fri, Dec 12, 2008 at 3:51 AM, Brian E. Fox <br...@reply.infinity.nu>
>> wrote:
>>
>>> I think most of these ideas are already covered in the lifecycle
>>> proposal out there that john wrote.
>>>
>>
>> Can you paste the link in please?
>>
>
> http://docs.codehaus.org/display/MAVEN/Deterministic+Lifecycle+Planning
>
> There are two linked docs at the bottom that are probably more relevant.
>
It's not clear to me from that proposal, how we could accommodate plugins
that need to update the pom...
For example, I'd like that versions-maven-plugin could work preemptively for
goals like update-parent...
Perhaps some mojos will need a way to run outside the lifecycle, or at least
signal that they could affect build plan determination somewhat... for
example, if I update the parent of some modules to a newer version, that
newer version may add/remove profiles, add/remove plugins, etc.
Perhaps that is covered in the Wiki, but it's just not clear to me
-Stephen
>
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: What will replace the @aggregator MOJO configuration?
Posted by Brett Porter <br...@apache.org>.
On 12/12/2008, at 6:57 AM, Barrie Treloar wrote:
> On Fri, Dec 12, 2008 at 3:51 AM, Brian E. Fox <brianf@reply.infinity.nu
> > wrote:
>> I think most of these ideas are already covered in the lifecycle
>> proposal out there that john wrote.
>
> Can you paste the link in please?
http://docs.codehaus.org/display/MAVEN/Deterministic+Lifecycle+Planning
There are two linked docs at the bottom that are probably more relevant.
- Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What will replace the @aggregator MOJO configuration?
Posted by Barrie Treloar <ba...@gmail.com>.
On Fri, Dec 12, 2008 at 3:51 AM, Brian E. Fox <br...@reply.infinity.nu> wrote:
> I think most of these ideas are already covered in the lifecycle
> proposal out there that john wrote.
Can you paste the link in please?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: What will replace the @aggregator MOJO configuration?
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
I think most of these ideas are already covered in the lifecycle
proposal out there that john wrote.
-----Original Message-----
From: Brett Porter [mailto:brett@apache.org]
Sent: Thursday, December 11, 2008 11:02 AM
To: Maven Developers List
Subject: Re: What will replace the @aggregator MOJO configuration?
On 07/12/2008, at 2:06 AM, Brian E. Fox wrote:
> Yes it's binding the aggregator with @execute to a lifecycle that is
> the
> problem. There's nothing wrong with aggregators that are meant to
> perform
> some action from the CLI. The trouble is that everyone ends up
> making two
> goals, one @aggregator and one xxx-only goal that is without the
> aggregator.
> I know of too many instances where someone bound an aggregator
> executor goal
> to a lifecycle and ended up with n*n-1 recursive builds or other crazy
> behavior.
>
> What I think we need is an annotation that says "execute up to this
> phase
> only if it hasn't already run" essentially a minimum phase execution.
>
> There also needs to be a way to attach a plugin to execute before the
> lifecycle to influence things like inject dependencies and we also
> need a
> way to bind to the very end of a build for cleanup or metric
> collection
> types of things.
Agreed. How do we pursue these ideas? Wiki?
Not sure how they fit in with the lifecycle refactoring of 3.0 or if
there's a bunch of these we could get happening sooner.
- Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What will replace the @aggregator MOJO configuration?
Posted by Brett Porter <br...@apache.org>.
On 07/12/2008, at 2:06 AM, Brian E. Fox wrote:
> Yes it's binding the aggregator with @execute to a lifecycle that is
> the
> problem. There's nothing wrong with aggregators that are meant to
> perform
> some action from the CLI. The trouble is that everyone ends up
> making two
> goals, one @aggregator and one xxx-only goal that is without the
> aggregator.
> I know of too many instances where someone bound an aggregator
> executor goal
> to a lifecycle and ended up with n*n-1 recursive builds or other crazy
> behavior.
>
> What I think we need is an annotation that says "execute up to this
> phase
> only if it hasn't already run" essentially a minimum phase execution.
>
> There also needs to be a way to attach a plugin to execute before the
> lifecycle to influence things like inject dependencies and we also
> need a
> way to bind to the very end of a build for cleanup or metric
> collection
> types of things.
Agreed. How do we pursue these ideas? Wiki?
Not sure how they fit in with the lifecycle refactoring of 3.0 or if
there's a bunch of these we could get happening sooner.
- Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What will replace the @aggregator MOJO configuration?
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Yes it's binding the aggregator with @execute to a lifecycle that is the
problem. There's nothing wrong with aggregators that are meant to perform
some action from the CLI. The trouble is that everyone ends up making two
goals, one @aggregator and one xxx-only goal that is without the aggregator.
I know of too many instances where someone bound an aggregator executor goal
to a lifecycle and ended up with n*n-1 recursive builds or other crazy
behavior.
What I think we need is an annotation that says "execute up to this phase
only if it hasn't already run" essentially a minimum phase execution.
There also needs to be a way to attach a plugin to execute before the
lifecycle to influence things like inject dependencies and we also need a
way to bind to the very end of a build for cleanup or metric collection
types of things.
On 12/5/08 7:59 PM, "Brett Porter" <br...@apache.org> wrote:
> On 06/12/2008, at 9:37 AM, Brian Fox wrote:
>
>> There's nothing presumptive about the fact that it HAS been
>> deprecated in trunk for quite some time now. (since it was still
>> called 2.1-snap)
>
> Ok, you're right, when binding to the lifecycle (which admittedly we
> are talking about here), though not generally.
>
> Aren't the source of these problems when it is used in conjunction
> with @execute? (Which is probably the more problematic annotation, I
> was never happy with the way that was done).
>
>>
>>
>> The aggregator is full of problems and usually leads to recursive
>> builds when you bind it to the lifecycle. A complely new concept is
>> needed to handle this use case.
>
> But doesn't yet exist, so perhaps a warning is more appropriate than a
> deprecation at this point. It does still work for the limited use
> cases it was designed for (such as the Nick is referring to).
>
> Cheers,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What will replace the @aggregator MOJO configuration?
Posted by Brett Porter <br...@apache.org>.
On 06/12/2008, at 9:37 AM, Brian Fox wrote:
> There's nothing presumptive about the fact that it HAS been
> deprecated in trunk for quite some time now. (since it was still
> called 2.1-snap)
Ok, you're right, when binding to the lifecycle (which admittedly we
are talking about here), though not generally.
Aren't the source of these problems when it is used in conjunction
with @execute? (Which is probably the more problematic annotation, I
was never happy with the way that was done).
>
>
> The aggregator is full of problems and usually leads to recursive
> builds when you bind it to the lifecycle. A complely new concept is
> needed to handle this use case.
But doesn't yet exist, so perhaps a warning is more appropriate than a
deprecation at this point. It does still work for the limited use
cases it was designed for (such as the Nick is referring to).
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What will replace the @aggregator MOJO configuration?
Posted by Brian Fox <br...@reply.infinity.nu>.
There's nothing presumptive about the fact that it HAS been deprecated
in trunk for quite some time now. (since it was still called 2.1-snap)
The aggregator is full of problems and usually leads to recursive
builds when you bind it to the lifecycle. A complely new concept is
needed to handle this use case.
--Brian (mobile)
On Dec 4, 2008, at 6:19 PM, Nick Pellow <np...@atlassian.com> wrote:
> Hi Brett,
>
>>
>>> Hi,
>>>
>>> I noticed that the 'aggregator' parameter for a MOJO is slated for
>>> deprecation in a future release of Maven.
>>> http://books.sonatype.com/maven-book/reference/writing-plugins.html#d0e22494
>>
>> Seems presumptive on the part of the author. It has both its
>> usefulness and its problems, and it being superceded is likely to
>> be part of a greater revision of the lifecycle rather than a one-
>> off deprecation.
>
> I agree. The @aggregator is certainly useful, and IMO the concept
> could even be extended to allow a user to specify that a specific
> goal should run as an aggregator.
> ie it would be great if a user could specify in the plugin
> configuration in the pom.xml that goal X should behave like an
> aggregator, or at least specify that goal X should only get run a
> single time at the executionRoot of the build. Does this make sense?
>
>
>>
>>
>>> What should be used instead, to fulfill the following use-case:
>>>
>>> - a multi-module project, which would like to assert something
>>> about the entire project at the very end of the build.
>>>
>>> A concrete example is mentioned on our Clover Forums at http://forums.atlassian.com/post!reply.jspa?messageID=257294857
>>> .
>>> The user would like to only run clover2:check on the entire
>>> project, not on each sub-module.
>>>
>>
>> @aggregator will work for your situation
>>
>> The only other solution available today is to run the plugin from a
>> separate module that depends on all the others (this is typically
>> how dependency-based aggregation is really done in Maven).
>
> Thanks for this work-around. I will mention that to the user.
>
> Cheers,
> Nick
>
>>
>>
>> Cheers,
>> Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What will replace the @aggregator MOJO configuration?
Posted by Nick Pellow <np...@atlassian.com>.
Hi Brett,
>
>> Hi,
>>
>> I noticed that the 'aggregator' parameter for a MOJO is slated for
>> deprecation in a future release of Maven.
>> http://books.sonatype.com/maven-book/reference/writing-plugins.html#d0e22494
>
> Seems presumptive on the part of the author. It has both its
> usefulness and its problems, and it being superceded is likely to be
> part of a greater revision of the lifecycle rather than a one-off
> deprecation.
I agree. The @aggregator is certainly useful, and IMO the concept
could even be extended to allow a user to specify that a specific goal
should run as an aggregator.
ie it would be great if a user could specify in the plugin
configuration in the pom.xml that goal X should behave like an
aggregator, or at least specify that goal X should only get run a
single time at the executionRoot of the build. Does this make sense?
>
>
>> What should be used instead, to fulfill the following use-case:
>>
>> - a multi-module project, which would like to assert something
>> about the entire project at the very end of the build.
>>
>> A concrete example is mentioned on our Clover Forums at http://forums.atlassian.com/post!reply.jspa?messageID=257294857
>> .
>> The user would like to only run clover2:check on the entire
>> project, not on each sub-module.
>>
>
> @aggregator will work for your situation
>
> The only other solution available today is to run the plugin from a
> separate module that depends on all the others (this is typically
> how dependency-based aggregation is really done in Maven).
Thanks for this work-around. I will mention that to the user.
Cheers,
Nick
>
>
> Cheers,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What will replace the @aggregator MOJO configuration?
Posted by Brett Porter <br...@apache.org>.
On 04/12/2008, at 12:29 PM, Nick Pellow wrote:
> Hi,
>
> I noticed that the 'aggregator' parameter for a MOJO is slated for
> deprecation in a future release of Maven.
> http://books.sonatype.com/maven-book/reference/writing-plugins.html#d0e22494
Seems presumptive on the part of the author. It has both its
usefulness and its problems, and it being superceded is likely to be
part of a greater revision of the lifecycle rather than a one-off
deprecation.
> What should be used instead, to fulfill the following use-case:
>
> - a multi-module project, which would like to assert something about
> the entire project at the very end of the build.
>
> A concrete example is mentioned on our Clover Forums at http://forums.atlassian.com/post!reply.jspa?messageID=257294857
> .
> The user would like to only run clover2:check on the entire project,
> not on each sub-module.
>
@aggregator will work for your situation
The only other solution available today is to run the plugin from a
separate module that depends on all the others (this is typically how
dependency-based aggregation is really done in Maven).
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org