Sure, I'm all for inter-phase-ordering, if altering the lifecycle and syntax is up for debate. A consolidation goal is definitely a work-around.
I am just really against the pre/post thing. It seems very hacky, and very hand-holdy (who can say if I only need three goals per phase?) Eric 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] > >
