Re: What will replace the @aggregator MOJO configuration?
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 On 12/12/2008, at 6:57 AM, Barrie Treloar wrote: On Fri, Dec 12, 2008 at 3:51 AM, Brian E. Fox > 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 br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: What will replace the @aggregator MOJO configuration?
2008/12/15 Brett Porter > > On 12/12/2008, at 6:57 AM, Barrie Treloar wrote: > > On Fri, Dec 12, 2008 at 3:51 AM, Brian E. Fox >> 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 > br...@apache.org > http://blogs.exist.com/bporter/ > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: What will replace the @aggregator MOJO configuration?
On 12/12/2008, at 6:57 AM, Barrie Treloar wrote: On Fri, Dec 12, 2008 at 3:51 AM, Brian E. Fox > 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 br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: What will replace the @aggregator MOJO configuration?
On Fri, Dec 12, 2008 at 3:51 AM, Brian E. Fox 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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: What will replace the @aggregator MOJO configuration?
I think most of these ideas are already covered in the lifecycle proposal out there that john wrote. -Original Message- From: Brett Porter [mailto:br...@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 br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
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 [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What will replace the @aggregator MOJO configuration?
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" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What will replace the @aggregator MOJO configuration?
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" <[EMAIL PROTECTED]> 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 >> [EMAIL PROTECTED] >> http://blogs.exist.com/bporter/ >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What will replace the @aggregator MOJO configuration?
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" <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > http://blogs.exist.com/bporter/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What will replace the @aggregator MOJO configuration?
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 [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What will replace the @aggregator MOJO configuration?
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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What will replace the @aggregator MOJO configuration?
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 [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What will replace the @aggregator MOJO configuration?
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 [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
