Isn't there a similar problem on linux systems to start services ?
AFAIK it uses shells orderings by adding order numbers, and the script
update-rc.d is used to add a new service at an expected position if
possible.
Maybe it could be a good inspiration for maven plugins ordering ?
Nico.
Allison, Bob a écrit :
Here's an idea for how to accomplish ordering:
Pick a number as the number of possible goals in a phase, say 25. The
value for the order would then range from 1 to that number minus 1 (1 to
24 in this case). Each standard plugin would define their place in the
sequence (either in the source code as an annotation or in the
components.xml file) and probably use a fixed number for consistency
sake; for the sake of this example we will use 12 as the standard
sequence number.
In a project's POM, the user maps the goal to the phase and sequence
number; numbers less than 12 (in this case) become pre-phase and numbers
greater than 12 become post-phase. If we allow a user to specify the
standard goal for the phase and a new sequence number, it allows the
user to adjust the execution order of even the standard plugins. If we
allow the user to specify a sequence number of 0 as "don't run this", we
allow the user to omit the standard goal without needing to do anything
within the mojo.
To allow for inheritance the way things are done now, as we process each
parent all sequence numbers are incremented by 25 (in this example) to
prevent overlaps. For an example in a project with two generations of
parents, the grandparent's goals would have numbers between 1 and 24,
the parent's between 26 and 49, and the project's between 51 and 74.
Each project would have specified numbers in the 1 to 24 range, the
numbers are adjusted internally while assembling the inheritance.
How it might look in the POM (and perhaps in the components.xml):
<plugin>
<sequence>6</sequence>
<plugin>
How it might look in the source code:
/**
* @sequence 6
*/
Default ordering if none is specified in the project's POM would be to
use the last order numbers available. In this example if a POM had
three goals mapped to a phase, they would be given sequence numbers 22,
23, and 24 in the order specified in the POM. If multiple goals end up
with the same number, they are executed in a random (at least to the
user) sequence.
I think this would allow the average user to ignore sequencing entirely,
allow declared plugins to have default places (pre-phase, phase, or
post-phase), provide pre-phase and post-phase capabilities for all
phases, and allow the bold and daring users to reassemble the build
order in any manner they deem appropriate.
Comments?
-----Original Message-----
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Friday, February 17, 2006 11:26
To: Maven Developers List
Subject: Re: [proposal] adding pre/post phases for all major lifecycle
phases
I understand that this is sort of a slippery slope WRT when we stop
adding new phases. While there are major categories for the phases of a
build, things like the following could occur:
I generate a model using Modello, and would like to use my own custom
Antlr grammar to create instances of that model.
Both should fit in generate-sources, but there's a definite order here.
Maybe the solution is to split the project in two, one -model, and
another -parser or something. Still, it seems like we're putting a
band-aid on the problem by adding more phases. Would it be better to add
control over ordering within a phase? How would that even look in
syntax?
What do you all think?
-j
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
