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
