Mailing-List: contact m2-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven 2 Developers List" <m2-dev@maven.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Subject: Re: Jason's lifecycle doco
From: "Mark H. Wilkinson" <mhw-m2-dev@kremvax.net>
To: Maven 2 Developers List <m2-dev@maven.apache.org>
In-Reply-To: <1106424475.4491.37.camel@localhost.localdomain>
References: <41F24386.7000404@apache.org>
	 <1106424475.4491.37.camel@localhost.localdomain>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Mon, 24 Jan 2005 09:12:00 +0000
Message-Id: <1106557920.5975.10.camel@sputnik.kremvax.net>
Mime-Version: 1.0

On Sat, 2005-01-22 at 12:07 -0800, Jason van Zyl wrote:
> On Sat, 2005-01-22 at 04:13, Brett Porter wrote:
> > - generating a site, which may well invoke other portions of this 
> > lifecycle (although it'll be great to ensure such things as tests don't 
> > get run again like they do now, unless its deliberate)
> 
> within that the analysis that Mark
> described would be invoked to prevent any duplicate work.

I think I'm right to say that the reason m1 has problems with goals
being run multiple times is the attainGoal element. The normal goal
graph that's built declaratively can be analysed to make sure a goal is
only executed once in a session. Goals called through attainGoal aren't
(and can't be in general) part of this analysis.

If we can model the whole of the build process as a graph we can analyse
it to prevent things being executed more than once. If we leave an
escape hatch for plugins to invoke goals as part of their execution
we're likely to lose this ability. (I think we're safe here, as I
presume the plugin interface won't be extended to allow plugins to
invoke goals.)

-Mark.