+1 Now that I like
On 2/17/06, Jesse McConnell <[EMAIL PROTECTED]> wrote: > > if we need to build out a way to get it done, then I rather like the idea > of > being able to define a ordering of things inside of a phase, and then bind > the plugins to that ordering... just to get it done in as clear as way as > possible... > > <project> > <lifecycle> > <phases> > <phase> > <name>compile</name> > <ordering> > <order>compile-one</order> > <order>compile-two</order> > <ordering> > . > . > . > > then in the plugin bind the phase to compile-one > > jesse > > 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 > > > > > -- > jesse mcconnell > jesseDOTmcconnellATgmailDOTcom > >
