That's the existing process, where the next mojo to be executed is
discovered based on the metadata of the current one...if the current
mojo requires a fork, the mojos to be included in that fork are
calculated just before the forking mojo is executed. As you go
through the build, executing
I've been thinking for awhile now that we need to find a way to
enable the more common programmatic semantics for mojo ordering...for
instance:
- finally semantics, where a mojo is /always/ executed after another
mojo, regardless of failure status...the only question here is shared
with t
No.
New lifecycle phases is a hack, to work around the bigger issue of
not having control over mojo-execution ordering and expression. IMO
we need to deal with the core issue, not continue to treat the symptoms.
-john
On Feb 11, 2008, at 3:44 AM, Wouter Hermeling wrote:
Reading through
t: Monday, 11 February 2008 7:34 PM
> To: Maven Developers List
> Subject: [***POSSIBLE SPAM***] - Re: Please comment: 2.1
> Lifecycle Features on MAVEN Confluence space - Bayesian
> Filter detected spam
>
> From
> http://docs.codehaus.org/display/MAVEN/Suppression%2C+Ord
Hi John,
That looks very interesting!
BTW, what is 'Just-in-time lifecycle discovery and configuration'?
Rahul
John Casey wrote:
Hi all,
I've written up the new features present in the refactored lifecycle
support for 2.1, if anyone is interested in reading it. I'd like to
hear what you
Hmmm, spotted that one of my wishes got into my description of the "current"
main lifecycle, i.e. process-test-classes
I'm thinking that some of those process- phases are also hacks!
Once we have the ability to control the sequence of execution, those
process- phases could be removed... giving us
From
http://docs.codehaus.org/display/MAVEN/Suppression%2C+Ordering%2C+and+Replacement+of+Plugins+and+Mojos+Bindings
one critical advantage of Maven over Ant or other build systems is its
universal, intuitive set of verbs used to build any project, it is
imperative
that we preserve the meaning of t
Reading through the Deterministic Lifecycle Planning page...
Do these changes make it possible to create new lifecycle phases???
Imho this would really help maven to become an extendable build/project
management tool for multiple platforms and purposes.
--
View this message in context:
http:/
Yeah, upon thinking about this a little more, I think it could be a really
bad idea to expose the "live" BuildPlan to plugins, at least without making
it a read-only view. Instead, I'd much rather provide a second extension
point for Maven that's well-defined and well-documented like the basic Mojo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
| Right...I guess it'd help to include the URL:
|
| http://docs.codehaus.org/display/MAVEN/Deterministic+Lifecycle+Planning
|
| Thanks!
I generally agree with what you are saying.
You are pointing out common problems very well.
The solution
to happen from each child artifact but before the build
plan is completely calculated so that it would affect the ordering.
-Original Message-
From: Jesse McConnell [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 31, 2008 3:19 PM
To: Maven Developers List
Subject: Re: Please comment: 2.1 L
yes, I see what your talking about..
And I think your might be onto something with your BuildPlanModifier
bit...It seems to me that plugins have perhaps grown a bit too...powerful in
terms of how they can effect the build.
I wonder if it might be a good time while your looking into all of this to
You know, I've been thinking about that bit, too...turning mojos off,
replacing them, etc, I mean. What I'm currently thinking is that a
build extension that carried its own configuration might be a good
alternative, though I'm not sure how well that would scale. The idea
is to introduce a
well, when your working with something that will try and predetermine how
and when plugins will run and you have something like build context/state in
play then plugins will be able to turn themselves off depending on build
state based on the context of the build up to that point...which kinda
inte
How do you see that impacting the lifecycle stuff, out of curiosity?
I did put the build context into trunk, but wound up taking it back
out because it wasn't implemented very well, and was leading to a
proliferation of separate, threadlocal-driven storage classes. I've
been thinking for aw
Do you think this will also include the build context mechanics we talked
about a long time ago? Where mojo's can communicate to each other a map of
either status or configuration settings through some third party mechanism,
perhaps the build plan this talks about. I seem to remember you putting
s
Right...I guess it'd help to include the URL:
http://docs.codehaus.org/display/MAVEN/Deterministic+Lifecycle+Planning
Thanks!
-john
On Jan 29, 2008, at 4:58 PM, John Casey wrote:
Hi all,
I've written up the new features present in the refactored
lifecycle support for 2.1, if anyone is int
Hi all,
I've written up the new features present in the refactored lifecycle
support for 2.1, if anyone is interested in reading it. I'd like to
hear what you all think, particularly about the emerging discussion
of aggregator plugins, pre-exec "plugins", and such taking place on
the page
18 matches
Mail list logo
