+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] > >
