So, you're suggesting scrapping the lifecycle altogether and going with
a required ordering scheme in the POM? I think that's a bit drastic for
the average user. Also, it's important that we provide some sort of
shorthand to keep users from needing to know what lifecycle bindings are
introduced by the packaging. You shouldn't need to deal with the
ordering of the default mojos in the 'jar' packaging, for example.
-j
Eric Redmond wrote:
I agree with your sentiments here, basically. The problem is, the number of
things done to a build cannot always decrease. If you need to generate code,
compile it, and then use that code to generate and compile more, well, you
cannot avoid the fact that 4 steps are involved. At this point it becomes a
question of what is the easiest way to represent these steps into an easily
understandable sequence? (Or even a sequence at all, because that particular
case sounds more like a graph).
To me, I'd rather see the steps labeled into descreet units (ala
consolidated goal or inter-phase-ordering) to give a clearer big-picture
view. For example:
generate-resources:
1. generate ANLTR
2. compile grammer
3. generate java code from it
compile:
1. compile java code
Or in graph form?
generate-resources:
generate ANLTR
compile:
compile grammer
generate-resources:
generate java code from it
compile:
compile java code
Rather than:
generate-resources (pre):
generate ANLTR
generate-resources:
compile grammer
generate-resources (post):
generate java code from it
compile:
compile java code
On 2/17/06, Jesse McConnell <[EMAIL PROTECTED]> wrote:
I really wonder about adding in more complexity into the pom with things
like ordering...
one of the attractions of maven imo is that it facilitates making the
build
a simple thing, small easily digestable chunks of build process,
leveraging
the dependency mechanism to weave it all together. Adding in more phases,
or ordering within a phase just makes the pom get more and more complex
which (in my mind) defeats one of the goals of maven...
sure it is technically possible to glom as much as you can into a pom, but
understandability goes down quickly and we are left with a process that
isn't a scads better then the others, like maven is right now IMO. :)
I understand people are really used to combining as much as they can into
one building entity, but it that going to be our best practice?
jesse
On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote:
IMO a consolidation goal is another workaround. It's definitely possible
now, but if we had phase-ordering, we wouldn't need it, right?
-j
Eric Redmond wrote:
+0 to the pre/post phase. As it has been mentioned a million times
before,
what's the difference between the post of one phase, and the pre of
the
next.
However, I am seeing a need for more than a single execution per
stage.
I
like John's suggesting alot. It makes sense. Within a particular
phase,
I
have a list of goals that need met. With the pre/post thing, it is
effectively saying "You can have at most three goals met per phase".
Another
option is to have some sort of consolidation goal that would then be
called
on a phase, whose definition is an ordered list of goals, I kind of
like
this better, as it will keep the syntax cleaner, and honestly, how
often
do
you need to cram multiple goals into a phase? One or two at most?
Eric
On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote:
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
John Casey wrote:
Hi,
I'd like to add pre/post phases for all of the major lifecycle
phases
that don't already have it. I'm starting to see cases where a
particular
packaging maps multiple mojos to the same lifecycle phase, and this
means we cannot control that phase through the old
suppress-and-augment
approach anymore. I'll give you an example:
Say I have two mojos bound to the package phase, for lack of a
better
place. The first takes the tested code, and assembles the directory
structure for the archive. The second creates the archive. If I want
to
replace the first step, I can add a 'skip' flag to it, but I
*cannot*
bind a new mojo in its place; any new binding will be added after
the
second step. Obviously, it makes no sense to prepare an archive
directory structure *after* the archive is created.
This is not the first time we've discussed this sort of thing. We
have
pre/post phases for setup and tear-down of integration tests, and
should
probably have something similar for unit tests...not to mention,
install, deploy...
It doesn't seem like a good idea to continue addressing this problem
an
issue at a time in successive Maven releases. Why not make a
reasonable
concession to these use cases, and add pre/post phases to each major
lifecycle phase (those which are themselves pre/post phases are not
what
I consider major).
I'd like to get this into 2.0.3, since it affects some work I'm
doing
for a client.
What do you all think?
-john
---------------------------------------------------------------------
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]
--
jesse mcconnell
jesseDOTmcconnellATgmailDOTcom
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
