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