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,
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 bri...@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
On 12/12/2008, at 6:57 AM, Barrie Treloar wrote:
On Fri, Dec 12, 2008 at 3:51 AM, Brian E. Fox bri...@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?
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
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
On Fri, Dec 12, 2008 at 3:51 AM, Brian E. Fox bri...@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
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
*
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.
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
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
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
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
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
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
14 matches
Mail list logo
