You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by John Casey <jd...@commonjava.org> on 2006/02/17 16:48:04 UTC
[proposal] adding pre/post phases for all major lifecycle phases
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by Eric Redmond <er...@gmail.com>.
Yes. My last job was working for a government-regulated project. The problem
was, that they got write-off from the FDA of their build system 10 years
ago. There was no way it could change (which is unfortunate, because it
sucked). So I wrote a maven front-end to the packaging system, so at least
the developers could leverage things like Maven and CVS. However, the
project structure still had to interact with that legacy build system for
legal reasons. If it weren't for Maven's flexibility in that matter, we
never could have used it.
IMO it is enough simply to make it easier to create new projects in a
correct way. New projects will tend to do whats easiest at the time. Thats
almost a good case for making it complicated and ugly to add multiple steps
into a phase via an extension, rather than modifying the phases at its core.
But it still needs to be possible for those sad souls who cannot change
their project structures at all.
Eric
On 2/17/06, John Casey <jd...@yahoo.com> wrote:
>
> BTW, Jesse and I have already had this discussion off-list, but I wanted
> to reflect it in the thread. :-)
>
>
>
> I couldn't agree more, WRT new projects. Or where people have the
> ability to manage their project structures.
>
> My original example was of two source-generation processes in the same
> porject, but in reality this *really* should be split into multiple
> projects:
>
> project-model
> project-parser
> project-*
>
> in the same way Maven itself is split up.
>
> HOWEVER, I think we also need to understand that there are going to be
> legacy use cases out there, where people don't have control over the
> project structure. If someone can't split up their project like above,
> do we want to turn them away at the door? In the past, I think Maven has
> tended to focus a little too tightly on new project development. IMO, we
> need to be more careful to accommodate these legacy cases in the future.
>
> To be clear, I don't want to encourage bad project design. I'm very much
> against shoving everything into one build just because it's possible.
> But, it should be possible, in order to accommodate those users who are
> dealing with bad project design that is outside of their control.
>
> Cheers,
>
> John
>
> Jesse McConnell 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 <jd...@yahoo.com> 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 <jd...@yahoo.com> 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: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
> > --
> > jesse mcconnell
> > jesseDOTmcconnellATgmailDOTcom
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by John Casey <jd...@yahoo.com>.
BTW, Jesse and I have already had this discussion off-list, but I wanted
to reflect it in the thread. :-)
I couldn't agree more, WRT new projects. Or where people have the
ability to manage their project structures.
My original example was of two source-generation processes in the same
porject, but in reality this *really* should be split into multiple
projects:
project-model
project-parser
project-*
in the same way Maven itself is split up.
HOWEVER, I think we also need to understand that there are going to be
legacy use cases out there, where people don't have control over the
project structure. If someone can't split up their project like above,
do we want to turn them away at the door? In the past, I think Maven has
tended to focus a little too tightly on new project development. IMO, we
need to be more careful to accommodate these legacy cases in the future.
To be clear, I don't want to encourage bad project design. I'm very much
against shoving everything into one build just because it's possible.
But, it should be possible, in order to accommodate those users who are
dealing with bad project design that is outside of their control.
Cheers,
John
Jesse McConnell 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 <jd...@yahoo.com> 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 <jd...@yahoo.com> 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: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> --
> jesse mcconnell
> jesseDOTmcconnellATgmailDOTcom
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by Eric Redmond <er...@gmail.com>.
+1 Now that I like
On 2/17/06, Jesse McConnell <je...@gmail.com> 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 <je...@gmail.com> 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 <jd...@yahoo.com> 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 <jd...@yahoo.com> 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: dev-unsubscribe@maven.apache.org
> > > >>> For additional commands, e-mail: dev-help@maven.apache.org
> > > >>>
> > > >>>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > >> For additional commands, e-mail: dev-help@maven.apache.org
> > > >>
> > > >>
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> >
> > --
> > jesse mcconnell
> > jesseDOTmcconnellATgmailDOTcom
>
>
>
>
> --
> jesse mcconnell
> jesseDOTmcconnellATgmailDOTcom
>
>
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by John Casey <jd...@yahoo.com>.
next thing would be to talk about how inheritance/injection works with
this. I think it would have to be inherited treating each <phase/>
specification as an atom. That way, a phase ordering is never merged
from parent to child, but it can be overridden. Since we'd only be
imposing order on phases that are specified, we would still have to
merge in the phases of the overall lifecycle where there are no collisions.
--john
John Casey wrote:
> +1
>
> I think this would be good, but maybe we could apply it selectively?
> What I mean is, have a default ordering algorithm (like we do now), but
> override that algorithm for the phases specified here. Then, we don't
> have to specify everything in order to add some order.
>
> Also, would it be good to have some generic placeholders like
> <packaging-mojos/> or something, so we can say, "Add these in this order
> BEFORE we add the packaging mappings...even though I don't know what
> those are."
>
> -j
>
> Jesse McConnell 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 <je...@gmail.com> 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 <jd...@yahoo.com> 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 <jd...@yahoo.com> 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: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> --
>>> jesse mcconnell
>>> jesseDOTmcconnellATgmailDOTcom
>>
>>
>>
>>
>> --
>> jesse mcconnell
>> jesseDOTmcconnellATgmailDOTcom
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by John Casey <jd...@yahoo.com>.
+1
I think this would be good, but maybe we could apply it selectively?
What I mean is, have a default ordering algorithm (like we do now), but
override that algorithm for the phases specified here. Then, we don't
have to specify everything in order to add some order.
Also, would it be good to have some generic placeholders like
<packaging-mojos/> or something, so we can say, "Add these in this order
BEFORE we add the packaging mappings...even though I don't know what
those are."
-j
Jesse McConnell 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 <je...@gmail.com> 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 <jd...@yahoo.com> 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 <jd...@yahoo.com> 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: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> --
>> jesse mcconnell
>> jesseDOTmcconnellATgmailDOTcom
>
>
>
>
> --
> jesse mcconnell
> jesseDOTmcconnellATgmailDOTcom
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by Jesse McConnell <je...@gmail.com>.
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 <je...@gmail.com> 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 <jd...@yahoo.com> 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 <jd...@yahoo.com> 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: dev-unsubscribe@maven.apache.org
> > >>> For additional commands, e-mail: dev-help@maven.apache.org
> > >>>
> > >>>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: dev-help@maven.apache.org
> > >>
> > >>
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> --
> jesse mcconnell
> jesseDOTmcconnellATgmailDOTcom
--
jesse mcconnell
jesseDOTmcconnellATgmailDOTcom
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by John Casey <jd...@yahoo.com>.
I'm not sure that's enough, actually. There will be times (there already
are) when people will want to set a flag that suppresses the default
mojo for a particular phase in the lifecycle mapped by a packaging, then
substitute in their own. If that mojo happens to fall ahead of another
mojo that's also bound by the packaging, this won't be possible unless
we have a way for specifying the default mojos in the ordering too...
Or, were you addressing the comment about a shorthand? If so, I agree
that's not absolutely required, since people customizing to this level
are probably going to know what the default lifecycle mappings are.
-j
Jesse McConnell wrote:
> 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 <jd...@yahoo.com> 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 <je...@gmail.com> 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 <jd...@yahoo.com> 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 <jd...@yahoo.com> 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: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>> --
>>>> jesse mcconnell
>>>> jesseDOTmcconnellATgmailDOTcom
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> --
> jesse mcconnell
> jesseDOTmcconnellATgmailDOTcom
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by Jesse McConnell <je...@gmail.com>.
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 <jd...@yahoo.com> 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 <je...@gmail.com> 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 <jd...@yahoo.com> 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 <jd...@yahoo.com> 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: dev-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>>
> >>
> >> --
> >> jesse mcconnell
> >> jesseDOTmcconnellATgmailDOTcom
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
jesse mcconnell
jesseDOTmcconnellATgmailDOTcom
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by John Casey <jd...@yahoo.com>.
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 <je...@gmail.com> 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 <jd...@yahoo.com> 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 <jd...@yahoo.com> 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: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> --
>> jesse mcconnell
>> jesseDOTmcconnellATgmailDOTcom
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by Eric Redmond <er...@gmail.com>.
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 <je...@gmail.com> 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 <jd...@yahoo.com> 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 <jd...@yahoo.com> 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: dev-unsubscribe@maven.apache.org
> > >>> For additional commands, e-mail: dev-help@maven.apache.org
> > >>>
> > >>>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: dev-help@maven.apache.org
> > >>
> > >>
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> --
> jesse mcconnell
> jesseDOTmcconnellATgmailDOTcom
>
>
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by Jesse McConnell <je...@gmail.com>.
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 <jd...@yahoo.com> 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 <jd...@yahoo.com> 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: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
jesse mcconnell
jesseDOTmcconnellATgmailDOTcom
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by Eric Redmond <er...@gmail.com>.
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 <jd...@yahoo.com> 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 <jd...@yahoo.com> 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: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by John Casey <jd...@yahoo.com>.
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 <jd...@yahoo.com> 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by Eric Redmond <er...@gmail.com>.
+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 <jd...@yahoo.com> 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by John Casey <jd...@yahoo.com>.
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by Stephen Duncan <st...@gmail.com>.
On 2/17/06, Brett Porter <br...@apache.org> wrote:
> This reply grabs bits from everywhere and summarises.
>
> Jesse McConnell wrote:
> > Providing a mechansim of strict execution ordering inside of a lifecycle
> > phase could address this..
>
> We already have an ordering (by inheritence, with profiles last,
> executions are in pom declared order within a phase). This is possibly
> limited. I think one of our items for 2.1 was to make this easier to
> specify and possibly order. But I'm worried about jumping in and out of
> things in different POMs within a phase. It seems wrong.
Just for feedback's sake: so far this worked perfectly for my case
without any thought about it. So I think any solution needs to be
equally as good at working without custom configuration.
Even though it worked, I was very unsure about whether it would, and
wasn't confident in it. Is there detailed documentation on the
current ordering anywhere?
--
Stephen Duncan Jr
www.stephenduncanjr.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by Jason van Zyl <ja...@maven.org>.
Brett Porter wrote:
> This reply grabs bits from everywhere and summarises.
>
> 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.
>
> For the record, I'm against this as the solution based on the thread so
> far. Some basic reasons before going into details:
> 1) pre/post is wrong in general, as pre-two = post-one. So we should
> have one phase between, but there we need an appropriate name. Likely
> this is something sensible and becomes a new lifecycle phase - just like
> we have now. Then we later discover that needs pre/post, and so on :) I
> think this really degrades to prereqs and pre/post goals that we had in
> m1/pre-alpha m2, which we eliminated for good reasons.
The pre/post thing I believe is really more grouping the execution of
your mojo with the appropriate phase. For example post processing
classes versus pre generating test sources.
I also don't think that this will degrade into m1 because we do have the
lifecycle.The default lifecycle and mojos we have bound to the phases in
that lifecycle should be compelling enough and satisfactory for 95% of
whatever you need to do. We already have structure where none existed
before in m1.
If we don't allow some flexibility here, whether pre/post phase or a
single mediating phase, is forcing users to use workarounds and put
things in seemingly unnatural places and making them wait for future
releases to support what they want. I am, of course, all for standards
but to leave no give I now think is unacceptable. I don't think it will
become commonplace to deviate from the default lifecycle because it's
just not convenient.
I would rather give people a little wiggle room there and incorporate
the feedback in subsequent releases instead of forcing users to wait for
the extensions simply because this is better for the user. We laid down
a solid framework and put the safety on, if the user wants to take the
safety off and see what the barrel tastes like then they take that risk.
I don't see this becoming common place but the flexibility will allow
people to uses releases and get out of jam if necessary. I don't see any
downside here other then us having to write a little more doco on why
writing your own lifecycle is a bad idea.
> 2) Some of this discussion around rearranging the lifecycle defeats the
> actual purpose of the lifecycle in the first place
I agree, reordering I would say is a bad idea.
>> It doesn't seem like a good idea to continue addressing this problem an
>> issue at a time in successive Maven releases.
>
> Actually, I think we should. That means we carefully assess each one and
> take care in adding it.
I think we can let users some freedom and put the onus on us to filter
out the salient use-cases put forward and integrate those suggestions
into the default lifecycle. It just puts the flexibility on the users
side of the equation. I think we may slowly approach covering 99% of
lifecycle requirements but that's going to take some time and the
inflexibility does the user a disservice.
>> I'd like to get this into 2.0.3, since it affects some work I'm doing
>> for a client.
>
> Since you have a workaround, I'd prefer we look at the proper solution
> for 2.1. I had great reservations about allowing this for integration
> tests in 2.0.2.
I think the approach of putting in the mediating phase(s) for 2.0.3|4 is
good if we take the approach of integrating those ideas in subsequently.
Users can stuff themselves now if they want, we aren't going to prevent
that by allowing some alternative nomenclature which is what pre/post is
essentially. I think that the pre/post hooks are a natural way for
extension given the solid foundation we've given in the form of the
default lifecycle. I'm getting soft in my old age :-)
The rest I think are concerns for 2.1 and can go in the wiki. Please
make sure it goes into the wiki or it will get lost in the mailing list
shuffle.
[snip]
> - Brett
jvz.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by Brett Porter <br...@apache.org>.
This reply grabs bits from everywhere and summarises.
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.
For the record, I'm against this as the solution based on the thread so
far. Some basic reasons before going into details:
1) pre/post is wrong in general, as pre-two = post-one. So we should
have one phase between, but there we need an appropriate name. Likely
this is something sensible and becomes a new lifecycle phase - just like
we have now. Then we later discover that needs pre/post, and so on :) I
think this really degrades to prereqs and pre/post goals that we had in
m1/pre-alpha m2, which we eliminated for good reasons.
2) Some of this discussion around rearranging the lifecycle defeats the
actual purpose of the lifecycle in the first place
> 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.
If you have a problem with suppress and augment as you've coined it, I'd
suggest your packaging might be too granular. Maybe you need a couple of
different packaging types?
> Say I have two mojos bound to the package phase, for lack of a better
> place.
This is a common example picked because I think we are missing the
prepare-package phase.
> It doesn't seem like a good idea to continue addressing this problem an
> issue at a time in successive Maven releases.
Actually, I think we should. That means we carefully assess each one and
take care in adding it.
> I'd like to get this into 2.0.3, since it affects some work I'm doing
> for a client.
Since you have a workaround, I'd prefer we look at the proper solution
for 2.1. I had great reservations about allowing this for integration
tests in 2.0.2.
Piéroni Raphaël wrote:
> can you add a post-compile-generate-resources phase ? sometimes a resource
> is generated (wsdl file) after the compile phase.
I thought we established this could just be generated directly to the
resources target. [MOJO-143]
Jesse McConnell wrote:
> Providing a mechansim of strict execution ordering inside of a lifecycle
> phase could address this..
We already have an ordering (by inheritence, with profiles last,
executions are in pom declared order within a phase). This is possibly
limited. I think one of our items for 2.1 was to make this easier to
specify and possibly order. But I'm worried about jumping in and out of
things in different POMs within a phase. It seems wrong.
John Casey wrote:
> 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.
Sorry, don't understand what the order is here (what is "creating an
instance of the model"?)
> Maybe the solution is to split the project in two, one -model, and
> another -parser or something.
This is a possible solution we should be considering in some cases, I think.
John Casey wrote:
> I'm not sure that's enough, actually. There will be times (there already
> are) when people will want to set a flag that suppresses the default
> mojo for a particular phase in the lifecycle mapped by a packaging, then
> substitute in their own.
While I don't like this, it might be a useful inclusion. I'd like to see
more specific examples - I'm worried that the things being excluded are
only doing so because the original mojo over-reached its duties (rather
than sensible defaults, it assumed too much about your environment and
isn't configurable enough).
Ok, to track back over this a bit, there are a few issues:
1) needing to exclude lifecycle phases
* I'd prefer not to. I think the packaging may be over reaching or the
involved mojos not configurable enough. Would like to see more examples.
2) ordering of lifecycle phases
* Do not want to customise the order of *phases*, that defeats the purpose.
* It appears sometimes there are multiple iterations of the same phases
(the axis example), see below.
3) ordering of goals in phases
* we already have this within a pom. We need examples of reasons it
needs to be ordered through inheritance (including profiles) in a way
that doesn't match the current parent first ordering.
* we have scope to improve this in 2.1 as we wanted to reassess at
least the declaration of goals.
Ok, things you can do to address issues here, some already mentioned:
1) split your project into two things. Sometimes this iterations
indicate you are building two different things with a dependency between
them
2) introduce a goal in the lifecycle that forks a new lifecycle to do
the generate, compile stage, then continue with generate, compile. This
is a form of iteration.
3) You can use compound goals to enforce ordering. This is similar to 2
in some ways. I don't think this is too hacky under the current arrangement.
4) We can explicitly allow iteration in 2.1. I think we already have
other use cases for this - eg to create both a regular jar and a debug
version of the jar every time. I'm not sure if this covers the axis
example though - maybe that is still done by (2).
5) We can improve the declaration of 1, 2, 3 in 2.1.
I suggest we try and make all our use cases work under (1), (2), (3),
and then aim to simplify them as a review of the lifecycle in 2.1 (we
also want to review forking in general, as it causes too much execution
in some instances).
How does this sound?
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by Raphaël Piéroni <ra...@gmail.com>.
Brett Porter a écrit :
> Raphaël Piéroni wrote:
>
>> - allow the adding of resource post compilation (to have the wsdl in the
>> jar)
>>
>
> You can do that by directly copying to target/classes in
> process-classes. What you are doing is really processing classes as much
> as generating resources. The only limitation is you can't filter them or
> do other resourcy things. Is that a need you have?
>
don't need filters
>
>> - move the generate-resources phase after compilation (as it is not
>> needed to compile, the only constraint is to have the resource well
>> placed before testing)
>>
>
> I think last time we considered this, there was a reason not to in
> general, and besides - backwards compatibility rules it out.
>
agree with backward compatibility
>
>> - create a new packaging (say axis-api) for axistools which binds the
>> generate-resource phase between compilation and test
>>
>
> This won't work, as a packaging can't define a new lifecycle ordering.
>
> Please refer to the other mail, and lets see if we can get this use case
> working under the 3 points I listed.
>
>
>> Maybe a way to get rid of the phases proliferation is to make
>> proliferate the packagings.
>> Therefore, the complexity of the phases are hidden in the
>> plugins-packaging and not shown in the pom which add the confusion to
>> the users.
>>
>> Is that makes sense ?
>>
>
> Yes, I thought that was the whole point of it right now. Doesn't the
> axis tools bind everything for you?
>
it does but by using the project helper (addResource) which is processed
before the compile i used a workaround by the antrun plugin.
Raphaël
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by Brett Porter <br...@apache.org>.
Raphaël Piéroni wrote:
> - allow the adding of resource post compilation (to have the wsdl in the
> jar)
You can do that by directly copying to target/classes in
process-classes. What you are doing is really processing classes as much
as generating resources. The only limitation is you can't filter them or
do other resourcy things. Is that a need you have?
> - move the generate-resources phase after compilation (as it is not
> needed to compile, the only constraint is to have the resource well
> placed before testing)
I think last time we considered this, there was a reason not to in
general, and besides - backwards compatibility rules it out.
> - create a new packaging (say axis-api) for axistools which binds the
> generate-resource phase between compilation and test
This won't work, as a packaging can't define a new lifecycle ordering.
Please refer to the other mail, and lets see if we can get this use case
working under the 3 points I listed.
> Maybe a way to get rid of the phases proliferation is to make
> proliferate the packagings.
> Therefore, the complexity of the phases are hidden in the
> plugins-packaging and not shown in the pom which add the confusion to
> the users.
>
> Is that makes sense ?
Yes, I thought that was the whole point of it right now. Doesn't the
axis tools bind everything for you?
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by Raphaël Piéroni <ra...@gmail.com>.
So if i understand how to fix my trouble with the axistools plugin :
To summarize my problem :
My problem is to add a new resource after compilation.
I had this problem because i want to create and API for web service and
generate the wsdl from that API.
Then use that API in the client side and server side and also use the
generated wsdl to generate java files.
There's now 2 ways : the wsdl file is added in the jar of the api or the
wsdl file is attached as a classifier to the api.jar
To fix the problem :
- allow the adding of resource post compilation (to have the wsdl in the
jar)
- move the generate-resources phase after compilation (as it is not
needed to compile, the only constraint is to have the resource well
placed before testing)
- create a new packaging (say axis-api) for axistools which binds the
generate-resource phase between compilation and test
The third one has my preference.
Maybe a way to get rid of the phases proliferation is to make
proliferate the packagings.
Therefore, the complexity of the phases are hidden in the
plugins-packaging and not shown in the pom which add the confusion to
the users.
Is that makes sense ?
Raphaël
John Casey a écrit :
> The more I think of it, the more I dislike this solution, actually. It
> simply doesn't address the larger problem, as Raphael inadvertently
> pointed out. ;-)
>
> The only trouble with strict ordering comes with the syntax, and
> dealing with the various layers of inheritance and injection. Plugin
> bindings can come from:
>
> 1. packaging lifecycle mapping
> 2. parent POM
> 3. profiles
> 4. POM
> 5. (am I missing something?)
>
> So, any syntax would have to support this layering in a way that
> wouldn't be overly confusing.
>
> FWIW, I think I have a band-aid on my client's project that will work
> for the time being. I'd much rather see this stuff fixed correctly
> soon, rather than have 10,000 lifecycle phases to support for backward
> compatibility later on...
>
> -john
>
> Jesse McConnell wrote:
>> +1 on this, with a caveat....it is a huge slippery slope that I think we
>> ought to be really clear on...especially since Raphaël already took
>> us down
>> the slope some more :P
>>
>> I am +1 for adding these in to address the immediate need with the
>> understanding that that is it and revisit the issue for the next
>> layer of
>> complexity with some type of ordering maybe..
>>
>> Providing a mechansim of strict execution ordering inside of a lifecycle
>> phase could address this.. Custom lifecycle phases and goals
>> declared in
>> the pom that can be bound by plugins inside of the pom? (icky)
>> Otherwise it
>> is just too easy to keep adding on layers of pre and post processing :)
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by Stephen Duncan <st...@gmail.com>.
I'll look into the issues. I should've remembered that it would sound
familiar, but I only spent a week on Maven 1 before moving to Maven
2... :)
-Stephen
On 2/17/06, Brett Porter <br...@apache.org> wrote:
> Hi Stephen,
>
> Stephen Duncan wrote:
> > Is ordering necessarily the right way to think about the problem? My
> > usage of Maven is fairly simple, so maybe I'm not really
> > conceptualizing some of the use cases. But I think about more in
> > terms of prerequisites. For instance, I have several assembly tasks
> > that I have attached to the package phase at the moment. For now it
> > seems to work due to luck/pom ordering.
>
>
> I won't go into them here, but prerequisites had a number of issues in
> Maven 1.x, and was part of the reason we moved to the lifecycle of m2.
> The original m2 had pre/post goals and prereqs. I'd expect you'd find
> more about this in the archives.
>
> I still believe the lifecycle concept is solid and have posted some more
> detailed thoughts in another mail.
>
> Thanks,
> Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Stephen Duncan Jr
www.stephenduncanjr.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by Brett Porter <br...@apache.org>.
Hi Stephen,
Stephen Duncan wrote:
> Is ordering necessarily the right way to think about the problem? My
> usage of Maven is fairly simple, so maybe I'm not really
> conceptualizing some of the use cases. But I think about more in
> terms of prerequisites. For instance, I have several assembly tasks
> that I have attached to the package phase at the moment. For now it
> seems to work due to luck/pom ordering.
I won't go into them here, but prerequisites had a number of issues in
Maven 1.x, and was part of the reason we moved to the lifecycle of m2.
The original m2 had pre/post goals and prereqs. I'd expect you'd find
more about this in the archives.
I still believe the lifecycle concept is solid and have posted some more
detailed thoughts in another mail.
Thanks,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by Stephen Duncan <st...@gmail.com>.
Is ordering necessarily the right way to think about the problem? My
usage of Maven is fairly simple, so maybe I'm not really
conceptualizing some of the use cases. But I think about more in
terms of prerequisites. For instance, I have several assembly tasks
that I have attached to the package phase at the moment. For now it
seems to work due to luck/pom ordering.
First, I also run dependency:copy-dependencies. If
performRelease=true is set, I run an assembly:assembly with a couple
of descriptors. One of those is zipping up the result of
copy-dependencies. So this goal has dependency:copy-dependencies as a
prerequisite.
Then I run assembly:directory with another descriptor to create a
directory that contains 1) the result of source:jar and javadoc:jar
(done automagically with performRelease=true), and 2) the results of
the assembly:assembly descriptor. So this goal should really have
three prerequisites: source:jar, javadoc:jar, and assembly:assembly
The positive side of looking at this way is that it keeps ordering
knowledge de-centralized. It would be analgous to a multi-project
build: based on prerequisites, Maven would determine the order to
execute the plugins that occur during the same lifecycle phase.
The downsides are: how would identify a particular execution as a
prerequisite? Would you always know your prerequisites, or just that
you should always be last (my assembly:directory actually outputs
target/*.jar and target/*.zip, for instance). Also I guess you'd
probably end up repeating yourself: I'd have to both specify the
prereq on javadoc:jar and source:jar, but also declare them (if they
weren't automatically down by having profiles with the same activation
property+value).
Sorry for thinking on e-paper here, but I'm hoping if I go through the
whole thought process, you guys with more experience might be able to
take more out of it.
Looking at my downsides, I have a more extreme suggestion. Rather
than specifying executions, and additionally specifying prerequisites,
could you just fully specify the prerequisite as a fully-defined
plugin/execution within another execution? If this were allowed to be
nested, it could solve at least a fair number of use cases. Does the
reactor currently handle build-ordering of nested levels of
subprojects? Or would this be a new foray into ordering resolution?
Anyhow, just my ideas to toss out. Any thoughts?
-Stephen
On 2/17/06, John Casey <jd...@yahoo.com> wrote:
> The more I think of it, the more I dislike this solution, actually. It
> simply doesn't address the larger problem, as Raphael inadvertently
> pointed out. ;-)
>
> The only trouble with strict ordering comes with the syntax, and dealing
> with the various layers of inheritance and injection. Plugin bindings
> can come from:
>
> 1. packaging lifecycle mapping
> 2. parent POM
> 3. profiles
> 4. POM
> 5. (am I missing something?)
>
> So, any syntax would have to support this layering in a way that
> wouldn't be overly confusing.
>
> FWIW, I think I have a band-aid on my client's project that will work
> for the time being. I'd much rather see this stuff fixed correctly soon,
> rather than have 10,000 lifecycle phases to support for backward
> compatibility later on...
>
> -john
>
> Jesse McConnell wrote:
> > +1 on this, with a caveat....it is a huge slippery slope that I think we
> > ought to be really clear on...especially since Raphaël already took us down
> > the slope some more :P
> >
> > I am +1 for adding these in to address the immediate need with the
> > understanding that that is it and revisit the issue for the next layer of
> > complexity with some type of ordering maybe..
> >
> > Providing a mechansim of strict execution ordering inside of a lifecycle
> > phase could address this.. Custom lifecycle phases and goals declared in
> > the pom that can be bound by plugins inside of the pom? (icky) Otherwise it
> > is just too easy to keep adding on layers of pre and post processing :)
> >
> >
> > my 2cents
> >
> > --
> >
> > to address the axistools pluign, we have discussed this on irc before. it
> > is completely reasonable to compile some classes, generate a wsdl off of
> > those classes for something like a server side wrapping of webservices and
> > then want to generate the client code off of that wsdl..
> >
> > but what we decided at the time was that it was also ok to just embed that
> > wsdl into the final jar and then in another project process that wsdl out of
> > the dependency jar and generate the client code...perhaps that can be
> > revisited, but the idea of having to support a compile -> generate sources
> > -> compile cycle is not one that has been addressed completely. Especially
> > since I have personally written 4 plugins that needed this type of cycle
> > already, and just swiped code out of the compiler mojo to do it :P
> >
> > jesse
> >
> >
> >
> > On 2/17/06, Piéroni Raphaël <ra...@gmail.com> wrote:
> >> +1
> >>
> >> can you add a post-compile-generate-resources phase ? sometimes a resource
> >> is generated (wsdl file) after the compile phase.
> >> for example, the axistool plugin needs for the classes to be generated in
> >> order to generated the wsdl files from them. and the plugin also try to
> >> add
> >> it to the resources.
> >>
> >> Raphaël
> >>
> >>
> >> 2006/2/17, Emmanuel Venisse <em...@venisse.net>:
> >>> +1
> >>>
> >>> Emmanuel
> >>>
> >>> John Casey a écrit :
> >>>> 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: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>>
> >
> >
> >
> > --
> > jesse mcconnell
> > jesseDOTmcconnellATgmailDOTcom
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by John Casey <jd...@yahoo.com>.
The more I think of it, the more I dislike this solution, actually. It
simply doesn't address the larger problem, as Raphael inadvertently
pointed out. ;-)
The only trouble with strict ordering comes with the syntax, and dealing
with the various layers of inheritance and injection. Plugin bindings
can come from:
1. packaging lifecycle mapping
2. parent POM
3. profiles
4. POM
5. (am I missing something?)
So, any syntax would have to support this layering in a way that
wouldn't be overly confusing.
FWIW, I think I have a band-aid on my client's project that will work
for the time being. I'd much rather see this stuff fixed correctly soon,
rather than have 10,000 lifecycle phases to support for backward
compatibility later on...
-john
Jesse McConnell wrote:
> +1 on this, with a caveat....it is a huge slippery slope that I think we
> ought to be really clear on...especially since Raphaël already took us down
> the slope some more :P
>
> I am +1 for adding these in to address the immediate need with the
> understanding that that is it and revisit the issue for the next layer of
> complexity with some type of ordering maybe..
>
> Providing a mechansim of strict execution ordering inside of a lifecycle
> phase could address this.. Custom lifecycle phases and goals declared in
> the pom that can be bound by plugins inside of the pom? (icky) Otherwise it
> is just too easy to keep adding on layers of pre and post processing :)
>
>
> my 2cents
>
> --
>
> to address the axistools pluign, we have discussed this on irc before. it
> is completely reasonable to compile some classes, generate a wsdl off of
> those classes for something like a server side wrapping of webservices and
> then want to generate the client code off of that wsdl..
>
> but what we decided at the time was that it was also ok to just embed that
> wsdl into the final jar and then in another project process that wsdl out of
> the dependency jar and generate the client code...perhaps that can be
> revisited, but the idea of having to support a compile -> generate sources
> -> compile cycle is not one that has been addressed completely. Especially
> since I have personally written 4 plugins that needed this type of cycle
> already, and just swiped code out of the compiler mojo to do it :P
>
> jesse
>
>
>
> On 2/17/06, Piéroni Raphaël <ra...@gmail.com> wrote:
>> +1
>>
>> can you add a post-compile-generate-resources phase ? sometimes a resource
>> is generated (wsdl file) after the compile phase.
>> for example, the axistool plugin needs for the classes to be generated in
>> order to generated the wsdl files from them. and the plugin also try to
>> add
>> it to the resources.
>>
>> Raphaël
>>
>>
>> 2006/2/17, Emmanuel Venisse <em...@venisse.net>:
>>> +1
>>>
>>> Emmanuel
>>>
>>> John Casey a écrit :
>>>> 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>
>
>
> --
> jesse mcconnell
> jesseDOTmcconnellATgmailDOTcom
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by Jesse McConnell <je...@gmail.com>.
+1 on this, with a caveat....it is a huge slippery slope that I think we
ought to be really clear on...especially since Raphaël already took us down
the slope some more :P
I am +1 for adding these in to address the immediate need with the
understanding that that is it and revisit the issue for the next layer of
complexity with some type of ordering maybe..
Providing a mechansim of strict execution ordering inside of a lifecycle
phase could address this.. Custom lifecycle phases and goals declared in
the pom that can be bound by plugins inside of the pom? (icky) Otherwise it
is just too easy to keep adding on layers of pre and post processing :)
my 2cents
--
to address the axistools pluign, we have discussed this on irc before. it
is completely reasonable to compile some classes, generate a wsdl off of
those classes for something like a server side wrapping of webservices and
then want to generate the client code off of that wsdl..
but what we decided at the time was that it was also ok to just embed that
wsdl into the final jar and then in another project process that wsdl out of
the dependency jar and generate the client code...perhaps that can be
revisited, but the idea of having to support a compile -> generate sources
-> compile cycle is not one that has been addressed completely. Especially
since I have personally written 4 plugins that needed this type of cycle
already, and just swiped code out of the compiler mojo to do it :P
jesse
On 2/17/06, Piéroni Raphaël <ra...@gmail.com> wrote:
>
> +1
>
> can you add a post-compile-generate-resources phase ? sometimes a resource
> is generated (wsdl file) after the compile phase.
> for example, the axistool plugin needs for the classes to be generated in
> order to generated the wsdl files from them. and the plugin also try to
> add
> it to the resources.
>
> Raphaël
>
>
> 2006/2/17, Emmanuel Venisse <em...@venisse.net>:
> >
> > +1
> >
> > Emmanuel
> >
> > John Casey a écrit :
> > > 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: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
--
jesse mcconnell
jesseDOTmcconnellATgmailDOTcom
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by Piéroni Raphaël <ra...@gmail.com>.
+1
can you add a post-compile-generate-resources phase ? sometimes a resource
is generated (wsdl file) after the compile phase.
for example, the axistool plugin needs for the classes to be generated in
order to generated the wsdl files from them. and the plugin also try to add
it to the resources.
Raphaël
2006/2/17, Emmanuel Venisse <em...@venisse.net>:
>
> +1
>
> Emmanuel
>
> John Casey a écrit :
> > 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [proposal] adding pre/post phases for all major lifecycle phases
Posted by Emmanuel Venisse <em...@venisse.net>.
+1
Emmanuel
John Casey a écrit :
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org