I say we force the lifecycle issue, just make it a little easier for someone to shove in an ordered sequence of plugins in the phase of their liking...that should address it nicely :)
jesse On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: > > 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] > > -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom
