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]