You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@maven.apache.org by Paul Benedict <pb...@apache.org> on 2014/06/04 15:57:08 UTC

Thoughts on MNG-3522

Anyone have thoughts on this ticket? There is a submitted patch, as the
last comment says -- it's part of another ticket that was marked as
duplicate.

Though, I am a bit confused. I thought plugin execution was already defined
by the sequential order listed in the POM. Am I incorrect? If so, I still
don't know if that's "good enough" when using POM inheritance.

Cheers,
Paul

Re: Thoughts on MNG-3522

Posted by Paul Benedict <pb...@apache.org>.

Yes, I do think plugins should have some sort of "ordinal" value associated
to them. However, I am not sure if I like the proposed patch because it
infers the order out of the plugin's <id> attribute (ex: step1, step2).
Certainly such a feature could work, but it hits that wall in Maven
development land: no one wants/can add new elements to the POM. Ideally,
there would be another element, like <order>, to control this.


Cheers,
Paul


On Wed, Jun 4, 2014 at 9:03 AM, Igor Fedorenko <ig...@ifedorenko.com> wrote:

> I haven't looked at the patch, but I know at least one case when it'd be
> nice to have explicit control over execution order within a build phase.
>
> Lets say you have two plugins, plugin-a with two goals a1 and a2, and
> plugin-b with goal b1. It is currently not possible to express the
> following execution order
>
>    plugin-a:a1
>    plugin-b:b1
>    plugin-a:a2
>
> Pack200 normalization, jar singing and pack200 packing during tycho
> build is real-world example where I had to artificially split pack200
> normalization and pack goals between two plugins to workaround this
> limitation.
>
> --
> Regards,
> Igor
>
>
> On 2014-06-04, 9:57, Paul Benedict wrote:
>
>> Anyone have thoughts on this ticket? There is a submitted patch, as the
>> last comment says -- it's part of another ticket that was marked as
>> duplicate.
>>
>> Though, I am a bit confused. I thought plugin execution was already
>> defined
>> by the sequential order listed in the POM. Am I incorrect? If so, I still
>> don't know if that's "good enough" when using POM inheritance.
>>
>> Cheers,
>> Paul
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Thoughts on MNG-3522

Posted by Igor Fedorenko <ig...@ifedorenko.com>.

I haven't looked at the patch, but I know at least one case when it'd be
nice to have explicit control over execution order within a build phase.

Lets say you have two plugins, plugin-a with two goals a1 and a2, and
plugin-b with goal b1. It is currently not possible to express the
following execution order

    plugin-a:a1
    plugin-b:b1
    plugin-a:a2

Pack200 normalization, jar singing and pack200 packing during tycho
build is real-world example where I had to artificially split pack200
normalization and pack goals between two plugins to workaround this
limitation.

--
Regards,
Igor

On 2014-06-04, 9:57, Paul Benedict wrote:
> Anyone have thoughts on this ticket? There is a submitted patch, as the
> last comment says -- it's part of another ticket that was marked as
> duplicate.
>
> Though, I am a bit confused. I thought plugin execution was already defined
> by the sequential order listed in the POM. Am I incorrect? If so, I still
> don't know if that's "good enough" when using POM inheritance.
>
> Cheers,
> Paul
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Thoughts on MNG-3522

Posted by Paul Benedict <pb...@apache.org>.

Sounds fine to me. I'll update the ticket with a link to this thread and a
summary of the "dependsOn" feature discussed here.


Cheers,
Paul


On Sun, Jun 8, 2014 at 9:02 AM, Jason van Zyl <ja...@takari.io> wrote:

> Agreed. Explicit order values are not good.
>
> It should be like the reactor in which the order is the topologically
> sorted list of projects. The executions in a phase should be the same,
> specify your dependencies and let the core topologically sort the
> executions and run them in the right order.  I think an attribute like
> dependsOn="${anotherExecutionId}" is in an execution element is fine.
>
> On Jun 8, 2014, at 9:42 AM, Igor Fedorenko <ig...@ifedorenko.com> wrote:
>
> > More I think about it, less I like the idea of explicit order values. I
> > think this will be rather inconvenient to setup and error prone to
> > maintain.
> >
> > Initial setup will require some tooling to see executions in a
> > particular case with their default ordering values. Not the end of the
> > world, but somebody will have to implement the tooling and the users
> > will know how to find it.
> >
> > More problematic will be ongoing changes to the project itself
> > and its parents. When I need to add/remove executions in a parent, I
> > will have to review all projects that inherit from it to ensure order is
> > still correct. I work on a monster codebase with 600+ modules now, I
> > just don't see how this is workable.
> >
> > If executions are enabled through a profile, especially rarely activated
> > profile, configuring expected order becomes really cumbersome.
> > Think of -Prelease profile, that adds gpg mojo to package phase...
> > good luck troubleshooting why signed jars do not match their gpg
> > signatures during the release.
> >
> > I think we need to find a way to make before/after hints work. I don't
> > have a proposal yet, but I wonder, is this not the same problem as
> > ordering modules in the reactor? When there are no dependencies, modules
> > are built in their specified order, but the order changes when there are
> > dependencies.
> >
> > --
> > Regards,
> > Igor
> >
> > On 2014-06-05, 11:11, Paul Benedict wrote:
> >> Igor, I can come up with three possible solutions which one I prefer.
> >>
> >> 1) Unspecified order plugins are all given highest precedence; specified
> >> plugins come after.
> >> 2) Unspecified order plugins are all given lowest precedence; specified
> >> plugins come before.
> >> 3) Unspecified order plugins are given a default precedence in steps of
> 100
> >> (ordered by declaration); specified plugins can be before, middle,
> after by
> >> choosing the appropriate number.
> >>
> >> I like #3. In your example, I would assign jarsigner precedence value
> 150
> >> to fit between pack200:normalize and pack200:goal.
> >>
> >>
> >>
> >>
> >> Cheers,
> >> Paul
> >>
> >>
> >> On Thu, Jun 5, 2014 at 9:38 AM, Paul Benedict <pb...@apache.org>
> wrote:
> >>
> >>> Good question. I haven't thought of that. In all the examples presented
> >>> thus far, the developer had control over all the <id> executions and
> >>> explicitly ordered them. This won't be the case all the time. What
> happens
> >>> when you mix ordering and unspecified?
> >>>
> >>>
> >>> Cheers,
> >>> Paul
> >>>
> >>>
> >>> On Thu, Jun 5, 2014 at 9:12 AM, Igor Fedorenko <ig...@ifedorenko.com>
> >>> wrote:
> >>>
> >>>> Mojo executions bound to in packaging type lifecycle mapping have
> fixed
> >>>> "default-<goal>" ids. To continue my Tycho pack200 example, I will
> need
> >>>> to insert jarsigner between pack200:normalize and pack200:pack goals.
> >>>> If pack200:normalize and pack200:pack goals are bound to the default
> >>>> lifecycle, can you explain how to achieve desired execution order with
> >>>> <id>s?
> >>>>
> >>>> --
> >>>> Regards,
> >>>> Igor
> >>>>
> >>>>
> >>>> On 2014-06-05, 9:52, Paul Benedict wrote:
> >>>>
> >>>>> After giving it some more thought, I think interpolating the <id> is
> less
> >>>>> disruptive than a new attribute. I am sure once POM 5 exists, there
> will
> >>>>> be
> >>>>> an official way.
> >>>>>
> >>>>> Lastly, I am not not a fan of the "step-#" naming because it's a
> prefix
> >>>>> but
> >>>>> it is more descriptive; I would prefer to just simply allow the
> developer
> >>>>> to suffix with a -# (dash number). Thoughts on which nomenclature is
> >>>>> better?
> >>>>>
> >>>>>
> >>>>> Cheers,
> >>>>> Paul
> >>>>>
> >>>>>
> >>>>> On Wed, Jun 4, 2014 at 10:59 AM, Igor Fedorenko <igor@ifedorenko.com
> >
> >>>>> wrote:
> >>>>>
> >>>>>  I am not sure xml attributes are necessary a hack. Whether to put
> >>>>>> before/after hints into xml element or attribute is really a matter
> of
> >>>>>> taste, imho.
> >>>>>>
> >>>>>> I don't want to restart the whole "pom v 5" discussion again, but I
> was
> >>>>>> under impression we agreed to preserve format published to maven
> >>>>>> repository but allow changes in the format used during the build.
> Which
> >>>>>> I believe implies that entire <build> section (or whaterver pom 5
> will
> >>>>>> end up using to represent build configuration) will be stripped out
> of
> >>>>>> pom.xml files before they are deployed.
> >>>>>>
> >>>>>> So I think it is okay to use xml attributes to represent
> before/after
> >>>>>> hints today and we can decide to change this to something else when
> we
> >>>>>> get to pom 5.
> >>>>>>
> >>>>>> --
> >>>>>> Regards,
> >>>>>> Igor
> >>>>>>
> >>>>>>
> >>>>>> On 2014-06-04, 11:39, Paul Benedict wrote:
> >>>>>>
> >>>>>>  Thanks for your reply Jason.
> >>>>>>>
> >>>>>>> So it seems there are some possibilities for this ticket: either
> >>>>>>> interpreting the <id> to infer order (the patch) or stuffing this
> into
> >>>>>>> an
> >>>>>>> attribute (per Igor). Regarding the latter, the attribute route is
> >>>>>>> clearly
> >>>>>>> to avoid adding a new POM element, but aren't both a bit
> "hackish"? The
> >>>>>>> desired solution, I think, would be to make this a POM element, but
> >>>>>>> past
> >>>>>>> discussions inform me that's clearly off the table.
> >>>>>>>
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>> Paul
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, Jun 4, 2014 at 10:20 AM, Jason van Zyl <ja...@takari.io>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>   I'm opposed to random creation of a DAG for executions across
> all the
> >>>>>>>
> >>>>>>>> phases. This just creates a giant mess. That said _within_ a given
> >>>>>>>> phase
> >>>>>>>> if
> >>>>>>>> there was a topological sorting of executions where one execution
> can
> >>>>>>>> state
> >>>>>>>> that it depends on another I think is reasonable. Definitive
> ordering
> >>>>>>>> within a phase, I think, is useful.
> >>>>>>>>
> >>>>>>>> On Jun 4, 2014, at 10:22 AM, Paul Benedict <pb...@apache.org>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>   I find that solution interesting because, in a way, it kind of
> >>>>>>>> returns
> >>>>>>>>
> >>>>>>>>> us
> >>>>>>>>> to the days of Maven 1.x where you can run things pre/post goal.
> I am
> >>>>>>>>> pretty sure Jason wanted to get rid of that perspective with
> this 2.x
> >>>>>>>>> design, but maybe things are coming full circle?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Cheers,
> >>>>>>>>> Paul
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko <
> igor@ifedorenko.com>
> >>>>>>>>>
> >>>>>>>>>  wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>   Yes, I was also thinking before/after as a way to solve this.
> We
> >>>>>>>>> can
> >>>>>>>>>
> >>>>>>>>>> probably use xml attributes without breaking compat with
> artifact
> >>>>>>>>>> consumers, so I think this can be done in Maven 3.x.
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Regards,
> >>>>>>>>>> Igor
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On 2014-06-04, 10:09, Robert Scholte wrote:
> >>>>>>>>>>
> >>>>>>>>>>   Hi Paul,
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> that's my understanding as well.
> >>>>>>>>>>> But even in a single pom you can have issues.
> >>>>>>>>>>> Consider 2 plugins, with both 2 goals and you want to run it
> like
> >>>>>>>>>>>
> >>>>>>>>>>> (phase=pre-integration-test)
> >>>>>>>>>>> pluginA:preSomething
> >>>>>>>>>>> pluginB:preStuff
> >>>>>>>>>>>
> >>>>>>>>>>> (phase=post-integration-test)
> >>>>>>>>>>> pluginB:postStuff
> >>>>>>>>>>> pluginA:postSomething
> >>>>>>>>>>>
> >>>>>>>>>>> Since plugins should be unique within the build-section, it's
> not
> >>>>>>>>>>> possible to have a clean solution for this.
> >>>>>>>>>>>
> >>>>>>>>>>> Instead of the step-X solution of MNG-4727 I think you should
> be
> >>>>>>>>>>> able
> >>>>>>>>>>>
> >>>>>>>>>>>  to
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>  run it before or after a specified goal.
> >>>>>>>>>
> >>>>>>>>>> We could think of using a convention for the execution-id, or
> >>>>>>>>>>> define a
> >>>>>>>>>>> new element in the pom-5.0.0
> >>>>>>>>>>>
> >>>>>>>>>>> thanks,
> >>>>>>>>>>>
> >>>>>>>>>>> Robert
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict
> >>>>>>>>>>> <pb...@apache.org>:
> >>>>>>>>>>>
> >>>>>>>>>>> Anyone have thoughts on this ticket? There is a submitted
> patch, as
> >>>>>>>>>>> the
> >>>>>>>>>>>
> >>>>>>>>>>>  last comment says -- it's part of another ticket that was
> marked
> >>>>>>>>>>>> as
> >>>>>>>>>>>> duplicate.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Though, I am a bit confused. I thought plugin execution was
> >>>>>>>>>>>> already
> >>>>>>>>>>>> defined
> >>>>>>>>>>>> by the sequential order listed in the POM. Am I incorrect? If
> so,
> >>>>>>>>>>>> I
> >>>>>>>>>>>>
> >>>>>>>>>>>>  still
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>  don't know if that's "good enough" when using POM inheritance.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>> Cheers,
> >>>>>>>>>>>> Paul
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>  ------------------------------------------------------------
> >>>>>>>>>>> ---------
> >>>>>>>>>>> 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
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>  Thanks,
> >>>>>>>>
> >>>>>>>> Jason
> >>>>>>>>
> >>>>>>>> ----------------------------------------------------------
> >>>>>>>> Jason van Zyl
> >>>>>>>> Founder,  Apache Maven
> >>>>>>>> http://twitter.com/jvanzyl
> >>>>>>>> http://twitter.com/takari_io
> >>>>>>>> ---------------------------------------------------------
> >>>>>>>>
> >>>>>>>> A language that doesn’t affect the way you think about
> programming is
> >>>>>>>> not
> >>>>>>>> worth knowing.
> >>>>>>>>
> >>>>>>>>    -- Alan Perlis
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
>  ---------------------------------------------------------------------
> >>>>>> 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
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
> First, the taking in of scattered particulars under one Idea,
> so that everyone understands what is being talked about ... Second,
> the separation of the Idea into parts, by dividing it at the joints,
> as nature directs, not breaking any limb in half as a bad carver might.
>
>   -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
>
>
>
>
>
>
>
>
>
>

Re: Thoughts on MNG-3522

Posted by Jason van Zyl <ja...@takari.io>.

Agreed. Explicit order values are not good.

It should be like the reactor in which the order is the topologically sorted list of projects. The executions in a phase should be the same, specify your dependencies and let the core topologically sort the executions and run them in the right order.  I think an attribute like dependsOn="${anotherExecutionId}" is in an execution element is fine.

On Jun 8, 2014, at 9:42 AM, Igor Fedorenko <ig...@ifedorenko.com> wrote:

> More I think about it, less I like the idea of explicit order values. I
> think this will be rather inconvenient to setup and error prone to
> maintain.
> 
> Initial setup will require some tooling to see executions in a
> particular case with their default ordering values. Not the end of the
> world, but somebody will have to implement the tooling and the users
> will know how to find it.
> 
> More problematic will be ongoing changes to the project itself
> and its parents. When I need to add/remove executions in a parent, I
> will have to review all projects that inherit from it to ensure order is
> still correct. I work on a monster codebase with 600+ modules now, I
> just don't see how this is workable.
> 
> If executions are enabled through a profile, especially rarely activated
> profile, configuring expected order becomes really cumbersome.
> Think of -Prelease profile, that adds gpg mojo to package phase...
> good luck troubleshooting why signed jars do not match their gpg
> signatures during the release.
> 
> I think we need to find a way to make before/after hints work. I don't
> have a proposal yet, but I wonder, is this not the same problem as
> ordering modules in the reactor? When there are no dependencies, modules
> are built in their specified order, but the order changes when there are
> dependencies.
> 
> --
> Regards,
> Igor
> 
> On 2014-06-05, 11:11, Paul Benedict wrote:
>> Igor, I can come up with three possible solutions which one I prefer.
>> 
>> 1) Unspecified order plugins are all given highest precedence; specified
>> plugins come after.
>> 2) Unspecified order plugins are all given lowest precedence; specified
>> plugins come before.
>> 3) Unspecified order plugins are given a default precedence in steps of 100
>> (ordered by declaration); specified plugins can be before, middle, after by
>> choosing the appropriate number.
>> 
>> I like #3. In your example, I would assign jarsigner precedence value 150
>> to fit between pack200:normalize and pack200:goal.
>> 
>> 
>> 
>> 
>> Cheers,
>> Paul
>> 
>> 
>> On Thu, Jun 5, 2014 at 9:38 AM, Paul Benedict <pb...@apache.org> wrote:
>> 
>>> Good question. I haven't thought of that. In all the examples presented
>>> thus far, the developer had control over all the <id> executions and
>>> explicitly ordered them. This won't be the case all the time. What happens
>>> when you mix ordering and unspecified?
>>> 
>>> 
>>> Cheers,
>>> Paul
>>> 
>>> 
>>> On Thu, Jun 5, 2014 at 9:12 AM, Igor Fedorenko <ig...@ifedorenko.com>
>>> wrote:
>>> 
>>>> Mojo executions bound to in packaging type lifecycle mapping have fixed
>>>> "default-<goal>" ids. To continue my Tycho pack200 example, I will need
>>>> to insert jarsigner between pack200:normalize and pack200:pack goals.
>>>> If pack200:normalize and pack200:pack goals are bound to the default
>>>> lifecycle, can you explain how to achieve desired execution order with
>>>> <id>s?
>>>> 
>>>> --
>>>> Regards,
>>>> Igor
>>>> 
>>>> 
>>>> On 2014-06-05, 9:52, Paul Benedict wrote:
>>>> 
>>>>> After giving it some more thought, I think interpolating the <id> is less
>>>>> disruptive than a new attribute. I am sure once POM 5 exists, there will
>>>>> be
>>>>> an official way.
>>>>> 
>>>>> Lastly, I am not not a fan of the "step-#" naming because it's a prefix
>>>>> but
>>>>> it is more descriptive; I would prefer to just simply allow the developer
>>>>> to suffix with a -# (dash number). Thoughts on which nomenclature is
>>>>> better?
>>>>> 
>>>>> 
>>>>> Cheers,
>>>>> Paul
>>>>> 
>>>>> 
>>>>> On Wed, Jun 4, 2014 at 10:59 AM, Igor Fedorenko <ig...@ifedorenko.com>
>>>>> wrote:
>>>>> 
>>>>>  I am not sure xml attributes are necessary a hack. Whether to put
>>>>>> before/after hints into xml element or attribute is really a matter of
>>>>>> taste, imho.
>>>>>> 
>>>>>> I don't want to restart the whole "pom v 5" discussion again, but I was
>>>>>> under impression we agreed to preserve format published to maven
>>>>>> repository but allow changes in the format used during the build. Which
>>>>>> I believe implies that entire <build> section (or whaterver pom 5 will
>>>>>> end up using to represent build configuration) will be stripped out of
>>>>>> pom.xml files before they are deployed.
>>>>>> 
>>>>>> So I think it is okay to use xml attributes to represent before/after
>>>>>> hints today and we can decide to change this to something else when we
>>>>>> get to pom 5.
>>>>>> 
>>>>>> --
>>>>>> Regards,
>>>>>> Igor
>>>>>> 
>>>>>> 
>>>>>> On 2014-06-04, 11:39, Paul Benedict wrote:
>>>>>> 
>>>>>>  Thanks for your reply Jason.
>>>>>>> 
>>>>>>> So it seems there are some possibilities for this ticket: either
>>>>>>> interpreting the <id> to infer order (the patch) or stuffing this into
>>>>>>> an
>>>>>>> attribute (per Igor). Regarding the latter, the attribute route is
>>>>>>> clearly
>>>>>>> to avoid adding a new POM element, but aren't both a bit "hackish"? The
>>>>>>> desired solution, I think, would be to make this a POM element, but
>>>>>>> past
>>>>>>> discussions inform me that's clearly off the table.
>>>>>>> 
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> Paul
>>>>>>> 
>>>>>>> 
>>>>>>> On Wed, Jun 4, 2014 at 10:20 AM, Jason van Zyl <ja...@takari.io>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>   I'm opposed to random creation of a DAG for executions across all the
>>>>>>> 
>>>>>>>> phases. This just creates a giant mess. That said _within_ a given
>>>>>>>> phase
>>>>>>>> if
>>>>>>>> there was a topological sorting of executions where one execution can
>>>>>>>> state
>>>>>>>> that it depends on another I think is reasonable. Definitive ordering
>>>>>>>> within a phase, I think, is useful.
>>>>>>>> 
>>>>>>>> On Jun 4, 2014, at 10:22 AM, Paul Benedict <pb...@apache.org>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>   I find that solution interesting because, in a way, it kind of
>>>>>>>> returns
>>>>>>>> 
>>>>>>>>> us
>>>>>>>>> to the days of Maven 1.x where you can run things pre/post goal. I am
>>>>>>>>> pretty sure Jason wanted to get rid of that perspective with this 2.x
>>>>>>>>> design, but maybe things are coming full circle?
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Cheers,
>>>>>>>>> Paul
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko <ig...@ifedorenko.com>
>>>>>>>>> 
>>>>>>>>>  wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>>>   Yes, I was also thinking before/after as a way to solve this. We
>>>>>>>>> can
>>>>>>>>> 
>>>>>>>>>> probably use xml attributes without breaking compat with artifact
>>>>>>>>>> consumers, so I think this can be done in Maven 3.x.
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Regards,
>>>>>>>>>> Igor
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On 2014-06-04, 10:09, Robert Scholte wrote:
>>>>>>>>>> 
>>>>>>>>>>   Hi Paul,
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> that's my understanding as well.
>>>>>>>>>>> But even in a single pom you can have issues.
>>>>>>>>>>> Consider 2 plugins, with both 2 goals and you want to run it like
>>>>>>>>>>> 
>>>>>>>>>>> (phase=pre-integration-test)
>>>>>>>>>>> pluginA:preSomething
>>>>>>>>>>> pluginB:preStuff
>>>>>>>>>>> 
>>>>>>>>>>> (phase=post-integration-test)
>>>>>>>>>>> pluginB:postStuff
>>>>>>>>>>> pluginA:postSomething
>>>>>>>>>>> 
>>>>>>>>>>> Since plugins should be unique within the build-section, it's not
>>>>>>>>>>> possible to have a clean solution for this.
>>>>>>>>>>> 
>>>>>>>>>>> Instead of the step-X solution of MNG-4727 I think you should be
>>>>>>>>>>> able
>>>>>>>>>>> 
>>>>>>>>>>>  to
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>  run it before or after a specified goal.
>>>>>>>>> 
>>>>>>>>>> We could think of using a convention for the execution-id, or
>>>>>>>>>>> define a
>>>>>>>>>>> new element in the pom-5.0.0
>>>>>>>>>>> 
>>>>>>>>>>> thanks,
>>>>>>>>>>> 
>>>>>>>>>>> Robert
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict
>>>>>>>>>>> <pb...@apache.org>:
>>>>>>>>>>> 
>>>>>>>>>>> Anyone have thoughts on this ticket? There is a submitted patch, as
>>>>>>>>>>> the
>>>>>>>>>>> 
>>>>>>>>>>>  last comment says -- it's part of another ticket that was marked
>>>>>>>>>>>> as
>>>>>>>>>>>> duplicate.
>>>>>>>>>>>> 
>>>>>>>>>>>> Though, I am a bit confused. I thought plugin execution was
>>>>>>>>>>>> already
>>>>>>>>>>>> defined
>>>>>>>>>>>> by the sequential order listed in the POM. Am I incorrect? If so,
>>>>>>>>>>>> I
>>>>>>>>>>>> 
>>>>>>>>>>>>  still
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>  don't know if that's "good enough" when using POM inheritance.
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Paul
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>  ------------------------------------------------------------
>>>>>>>>>>> ---------
>>>>>>>>>>> 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
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>  Thanks,
>>>>>>>> 
>>>>>>>> Jason
>>>>>>>> 
>>>>>>>> ----------------------------------------------------------
>>>>>>>> Jason van Zyl
>>>>>>>> Founder,  Apache Maven
>>>>>>>> http://twitter.com/jvanzyl
>>>>>>>> http://twitter.com/takari_io
>>>>>>>> ---------------------------------------------------------
>>>>>>>> 
>>>>>>>> A language that doesn’t affect the way you think about programming is
>>>>>>>> not
>>>>>>>> worth knowing.
>>>>>>>> 
>>>>>>>>    -- Alan Perlis
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>  ---------------------------------------------------------------------
>>>>>> 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
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------

First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.

  -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)

Re: Thoughts on MNG-3522

Posted by Paul Benedict <pb...@apache.org>.

That's where the theoretical "before" attribute would be useful, right?


Cheers,
Paul


On Thu, Jun 12, 2014 at 3:49 PM, Anders Hammar <an...@hammar.net> wrote:

> Sorry, my bad. I meant the binding in the child to be BEFORE the one on the
> parent. I can't alter the declaration in the parent in my scenario as I'm
> not on control of it.
>
> /Anders (mobile)
> Den 12 jun 2014 22:19 skrev "Anders Hammar" <an...@hammar.net>:
>
> >
> > Child modules can add configuration to mojo executions configured in
> >> parent pom. This isn't pretty, but works.
> >>
> >
> > That's not what I had in mind. I was talking about one plugin binding in
> > the parent pom and then a different plugin binding in the child, which we
> > want to be after the one in the parent. Then only having "dependsOn"
> > wouldn't work in a case where we can't update the parent.
> >
> >
> >> And, to be clear, I am not saying we shouldn't implement before/after
> >> configuration, I think it will be convenient to have both. All I am
> >> saying only one is truly required.
> >
> >
> > Not in the case I describe (I think).
> >
> >
> >>
> >> --
> >> Regards,
> >> Igor
> >>
> >> On 2014-06-12, 2:23, Anders Hammar wrote:
> >>
> >>>
> >>>> Having said that, I think having both "before" and "after" attributes
> >>>> will make configuration easier in some cases, but I still think all
> >>>> ordering can be expressed just with dependsOf (which is the same as
> >>>> "after").
> >>>>
> >>>
> >>>
> >>> Let's say you're not in control of the pom where the plugin binding is
> >>> declared, which you want to add a binding before. Then it is not
> possible
> >>> to add the "dependsOn". One scenario would be a parent pom you're
> >>> inheriting from.
> >>>
> >>> /Anders
> >>>
> >>>
> >>>
> >>>> --
> >>>> Regards,
> >>>> Igor
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On 2014-06-11, 15:44, Robert Scholte wrote:
> >>>>
> >>>>  The "dependsOn" would only help if this execution should be done
> >>>>> *after*
> >>>>> another execution. However, I think we also need a solution for the
> >>>>> *before* one, unless we say: just manage this by ordering your
> plugins.
> >>>>> Keep in mind: what to do if executions are defined in the parent and
> >>>>> you
> >>>>> want to execute your plugin before and/or after these inherited
> >>>>> executions?
> >>>>>
> >>>>> Thanks,
> >>>>> Robert
> >>>>>
> >>>>> Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko
> >>>>> <ig...@ifedorenko.com>:
> >>>>>
> >>>>>   Misconfigured execution order should be reported as build failer.
> >>>>>
> >>>>>>
> >>>>>> I don't see how profiles make this problem more complicated. It
> maybe
> >>>>>> little tedious to configure, but I believe it is always possible to
> >>>>>> add
> >>>>>> dependsOn attribute to execution defined elsewhere. So in your
> >>>>>> example,
> >>>>>> the release profile will need to define execution with id of the
> >>>>>> "final
> >>>>>> step" and add dependsOf="id-of-sign-step".
> >>>>>>
> >>>>>> --
> >>>>>> Regards,
> >>>>>> Igor
> >>>>>>
> >>>>>> On 2014-06-11, 15:17, Jörg Schaible wrote:
> >>>>>>
> >>>>>>  Hi Igor,
> >>>>>>>
> >>>>>>> Igor Fedorenko wrote:
> >>>>>>>
> >>>>>>>   More I think about it, less I like the idea of explicit order
> >>>>>>> values. I
> >>>>>>>
> >>>>>>>> think this will be rather inconvenient to setup and error prone to
> >>>>>>>> maintain.
> >>>>>>>>
> >>>>>>>> Initial setup will require some tooling to see executions in a
> >>>>>>>> particular case with their default ordering values. Not the end of
> >>>>>>>> the
> >>>>>>>> world, but somebody will have to implement the tooling and the
> users
> >>>>>>>> will know how to find it.
> >>>>>>>>
> >>>>>>>> More problematic will be ongoing changes to the project itself
> >>>>>>>> and its parents. When I need to add/remove executions in a
> parent, I
> >>>>>>>> will have to review all projects that inherit from it to ensure
> >>>>>>>> order is
> >>>>>>>> still correct. I work on a monster codebase with 600+ modules
> now, I
> >>>>>>>> just don't see how this is workable.
> >>>>>>>>
> >>>>>>>> If executions are enabled through a profile, especially rarely
> >>>>>>>> activated
> >>>>>>>> profile, configuring expected order becomes really cumbersome.
> >>>>>>>> Think of -Prelease profile, that adds gpg mojo to package phase...
> >>>>>>>> good luck troubleshooting why signed jars do not match their gpg
> >>>>>>>> signatures during the release.
> >>>>>>>>
> >>>>>>>> I think we need to find a way to make before/after hints work. I
> >>>>>>>> don't
> >>>>>>>> have a proposal yet, but I wonder, is this not the same problem as
> >>>>>>>> ordering modules in the reactor? When there are no dependencies,
> >>>>>>>> modules
> >>>>>>>> are built in their specified order, but the order changes when
> there
> >>>>>>>> are
> >>>>>>>> dependencies.
> >>>>>>>>
> >>>>>>>>
> >>>>>>> please have a look at the latest comments on MNG-3522, because
> adding
> >>>>>>> executions in a profile causes some edge cases, which should be
> >>>>>>> defined in
> >>>>>>> advance.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Jörg
> >>>>>>>
> >>>>>>>
> >>>>>>> ------------------------------------------------------------
> >>>>>>> ---------
> >>>>>>> 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
> >>>>>
> >>>>>
> >>>>>
>  ---------------------------------------------------------------------
> >>>> 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: Thoughts on MNG-3522

Posted by Anders Hammar <an...@hammar.net>.

Sorry, my bad. I meant the binding in the child to be BEFORE the one on the
parent. I can't alter the declaration in the parent in my scenario as I'm
not on control of it.

/Anders (mobile)
Den 12 jun 2014 22:19 skrev "Anders Hammar" <an...@hammar.net>:

>
> Child modules can add configuration to mojo executions configured in
>> parent pom. This isn't pretty, but works.
>>
>
> That's not what I had in mind. I was talking about one plugin binding in
> the parent pom and then a different plugin binding in the child, which we
> want to be after the one in the parent. Then only having "dependsOn"
> wouldn't work in a case where we can't update the parent.
>
>
>> And, to be clear, I am not saying we shouldn't implement before/after
>> configuration, I think it will be convenient to have both. All I am
>> saying only one is truly required.
>
>
> Not in the case I describe (I think).
>
>
>>
>> --
>> Regards,
>> Igor
>>
>> On 2014-06-12, 2:23, Anders Hammar wrote:
>>
>>>
>>>> Having said that, I think having both "before" and "after" attributes
>>>> will make configuration easier in some cases, but I still think all
>>>> ordering can be expressed just with dependsOf (which is the same as
>>>> "after").
>>>>
>>>
>>>
>>> Let's say you're not in control of the pom where the plugin binding is
>>> declared, which you want to add a binding before. Then it is not possible
>>> to add the "dependsOn". One scenario would be a parent pom you're
>>> inheriting from.
>>>
>>> /Anders
>>>
>>>
>>>
>>>> --
>>>> Regards,
>>>> Igor
>>>>
>>>>
>>>>
>>>>
>>>> On 2014-06-11, 15:44, Robert Scholte wrote:
>>>>
>>>>  The "dependsOn" would only help if this execution should be done
>>>>> *after*
>>>>> another execution. However, I think we also need a solution for the
>>>>> *before* one, unless we say: just manage this by ordering your plugins.
>>>>> Keep in mind: what to do if executions are defined in the parent and
>>>>> you
>>>>> want to execute your plugin before and/or after these inherited
>>>>> executions?
>>>>>
>>>>> Thanks,
>>>>> Robert
>>>>>
>>>>> Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko
>>>>> <ig...@ifedorenko.com>:
>>>>>
>>>>>   Misconfigured execution order should be reported as build failer.
>>>>>
>>>>>>
>>>>>> I don't see how profiles make this problem more complicated. It maybe
>>>>>> little tedious to configure, but I believe it is always possible to
>>>>>> add
>>>>>> dependsOn attribute to execution defined elsewhere. So in your
>>>>>> example,
>>>>>> the release profile will need to define execution with id of the
>>>>>> "final
>>>>>> step" and add dependsOf="id-of-sign-step".
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> Igor
>>>>>>
>>>>>> On 2014-06-11, 15:17, Jörg Schaible wrote:
>>>>>>
>>>>>>  Hi Igor,
>>>>>>>
>>>>>>> Igor Fedorenko wrote:
>>>>>>>
>>>>>>>   More I think about it, less I like the idea of explicit order
>>>>>>> values. I
>>>>>>>
>>>>>>>> think this will be rather inconvenient to setup and error prone to
>>>>>>>> maintain.
>>>>>>>>
>>>>>>>> Initial setup will require some tooling to see executions in a
>>>>>>>> particular case with their default ordering values. Not the end of
>>>>>>>> the
>>>>>>>> world, but somebody will have to implement the tooling and the users
>>>>>>>> will know how to find it.
>>>>>>>>
>>>>>>>> More problematic will be ongoing changes to the project itself
>>>>>>>> and its parents. When I need to add/remove executions in a parent, I
>>>>>>>> will have to review all projects that inherit from it to ensure
>>>>>>>> order is
>>>>>>>> still correct. I work on a monster codebase with 600+ modules now, I
>>>>>>>> just don't see how this is workable.
>>>>>>>>
>>>>>>>> If executions are enabled through a profile, especially rarely
>>>>>>>> activated
>>>>>>>> profile, configuring expected order becomes really cumbersome.
>>>>>>>> Think of -Prelease profile, that adds gpg mojo to package phase...
>>>>>>>> good luck troubleshooting why signed jars do not match their gpg
>>>>>>>> signatures during the release.
>>>>>>>>
>>>>>>>> I think we need to find a way to make before/after hints work. I
>>>>>>>> don't
>>>>>>>> have a proposal yet, but I wonder, is this not the same problem as
>>>>>>>> ordering modules in the reactor? When there are no dependencies,
>>>>>>>> modules
>>>>>>>> are built in their specified order, but the order changes when there
>>>>>>>> are
>>>>>>>> dependencies.
>>>>>>>>
>>>>>>>>
>>>>>>> please have a look at the latest comments on MNG-3522, because adding
>>>>>>> executions in a profile causes some edge cases, which should be
>>>>>>> defined in
>>>>>>> advance.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Jörg
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>>> ---------
>>>>>>> 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
>>>>>
>>>>>
>>>>>  ---------------------------------------------------------------------
>>>> 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: Thoughts on MNG-3522

Posted by Igor Fedorenko <ig...@ifedorenko.com>.

yes, I agree before/after will likely be more convenient in some cases.

--
Regards,
Igor

On 2014-06-12, 17:04, Robert Scholte wrote:
> I don't think this is a general use case.
>
> With the same parent, I believe this is a common example:
>
>       <plugin>
>         <groupId>com</groupId>
>         <artifactId>acme</artifactId>
>         <version>2.3</version>
>         <executions>
>           <execution> <!-- before, because of plugin order -->
>             <id>pre</id>
>             <phase>...</phase>
>             <goals><goal>...</goal></goals>
>           </execution>
>           <execution dependsOn="foo:bar#munchy">
>             <id>post</id>
>             <phase>...</phase>
>             <goals><goal>...</goal></goals>
>           </execution>
>         </executions>
>       <plugin>
>
>       <plugin>
>         <groupId>foo</groupId>
>         <artifactId>bar</artifactId>
>       <plugin>
>
> In this case you MUST specify the foo:bar plugin as well. Quite a lot of
> tags compared to @before="foo:bar#munchy", but with the same result.
> One tricky thing: allowing both @before and @after may cause circular
> executions more often.
> Another interesting thing from Igors example: is it allowed to change
> the order of existing/inherited execution blocks?
>
> thanks,
> Robert
>
>
> Op Thu, 12 Jun 2014 22:43:04 +0200 schreef Igor Fedorenko
> <ig...@ifedorenko.com>:
>
>> Consider the following parent pom.xml snippet
>>
>>     <plugin>
>>       <groupId>foo</groupId>
>>       <artifactId>bar</artifactId>
>>       <version>1</version>
>>       <executions>
>>         <execution>
>>           <id>munchy</id>
>>           <phase>...</phase>
>>           <goals><goal>...</goal></goals>
>>         </execution>
>>       </executions>
>>     <plugin>
>>
>> then in the child I believe you can do
>>
>>     <plugin>
>>       <groupId>foo</groupId>
>>       <artifactId>bar</artifactId>
>>       <version>1</version>
>>       <executions>
>>         <execution dependsOn="some-other-plugin-execution">
>>           <id>munchy</id>
>>           <!-- the rest of configuration is inherited from parent -->
>>         </execution>
>>       </executions>
>>     <plugin>
>>
>> --
>> Regards,
>> Igor
>>
>> On 2014-06-12, 16:19, Anders Hammar wrote:
>>>> Child modules can add configuration to mojo executions configured in
>>>> parent pom. This isn't pretty, but works.
>>>>
>>>
>>> That's not what I had in mind. I was talking about one plugin binding in
>>> the parent pom and then a different plugin binding in the child,
>>> which we
>>> want to be after the one in the parent. Then only having "dependsOn"
>>> wouldn't work in a case where we can't update the parent.
>>>
>>>
>>>> And, to be clear, I am not saying we shouldn't implement before/after
>>>> configuration, I think it will be convenient to have both. All I am
>>>> saying only one is truly required.
>>>
>>>
>>> Not in the case I describe (I think).
>>>
>>>
>>>>
>>>> --
>>>> Regards,
>>>> Igor
>>>>
>>>> On 2014-06-12, 2:23, Anders Hammar wrote:
>>>>
>>>>>
>>>>>> Having said that, I think having both "before" and "after" attributes
>>>>>> will make configuration easier in some cases, but I still think all
>>>>>> ordering can be expressed just with dependsOf (which is the same as
>>>>>> "after").
>>>>>>
>>>>>
>>>>>
>>>>> Let's say you're not in control of the pom where the plugin binding is
>>>>> declared, which you want to add a binding before. Then it is not
>>>>> possible
>>>>> to add the "dependsOn". One scenario would be a parent pom you're
>>>>> inheriting from.
>>>>>
>>>>> /Anders
>>>>>
>>>>>
>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> Igor
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2014-06-11, 15:44, Robert Scholte wrote:
>>>>>>
>>>>>>   The "dependsOn" would only help if this execution should be done
>>>>>> *after*
>>>>>>> another execution. However, I think we also need a solution for the
>>>>>>> *before* one, unless we say: just manage this by ordering your
>>>>>>> plugins.
>>>>>>> Keep in mind: what to do if executions are defined in the parent
>>>>>>> and you
>>>>>>> want to execute your plugin before and/or after these inherited
>>>>>>> executions?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Robert
>>>>>>>
>>>>>>> Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko
>>>>>>> <ig...@ifedorenko.com>:
>>>>>>>
>>>>>>>    Misconfigured execution order should be reported as build failer.
>>>>>>>
>>>>>>>>
>>>>>>>> I don't see how profiles make this problem more complicated. It
>>>>>>>> maybe
>>>>>>>> little tedious to configure, but I believe it is always possible
>>>>>>>> to add
>>>>>>>> dependsOn attribute to execution defined elsewhere. So in your
>>>>>>>> example,
>>>>>>>> the release profile will need to define execution with id of the
>>>>>>>> "final
>>>>>>>> step" and add dependsOf="id-of-sign-step".
>>>>>>>>
>>>>>>>> --
>>>>>>>> Regards,
>>>>>>>> Igor
>>>>>>>>
>>>>>>>> On 2014-06-11, 15:17, Jörg Schaible wrote:
>>>>>>>>
>>>>>>>>   Hi Igor,
>>>>>>>>>
>>>>>>>>> Igor Fedorenko wrote:
>>>>>>>>>
>>>>>>>>>    More I think about it, less I like the idea of explicit order
>>>>>>>>> values. I
>>>>>>>>>
>>>>>>>>>> think this will be rather inconvenient to setup and error
>>>>>>>>>> prone to
>>>>>>>>>> maintain.
>>>>>>>>>>
>>>>>>>>>> Initial setup will require some tooling to see executions in a
>>>>>>>>>> particular case with their default ordering values. Not the
>>>>>>>>>> end of
>>>>>>>>>> the
>>>>>>>>>> world, but somebody will have to implement the tooling and the
>>>>>>>>>> users
>>>>>>>>>> will know how to find it.
>>>>>>>>>>
>>>>>>>>>> More problematic will be ongoing changes to the project itself
>>>>>>>>>> and its parents. When I need to add/remove executions in a
>>>>>>>>>> parent, I
>>>>>>>>>> will have to review all projects that inherit from it to ensure
>>>>>>>>>> order is
>>>>>>>>>> still correct. I work on a monster codebase with 600+ modules
>>>>>>>>>> now, I
>>>>>>>>>> just don't see how this is workable.
>>>>>>>>>>
>>>>>>>>>> If executions are enabled through a profile, especially rarely
>>>>>>>>>> activated
>>>>>>>>>> profile, configuring expected order becomes really cumbersome.
>>>>>>>>>> Think of -Prelease profile, that adds gpg mojo to package
>>>>>>>>>> phase...
>>>>>>>>>> good luck troubleshooting why signed jars do not match their gpg
>>>>>>>>>> signatures during the release.
>>>>>>>>>>
>>>>>>>>>> I think we need to find a way to make before/after hints work. I
>>>>>>>>>> don't
>>>>>>>>>> have a proposal yet, but I wonder, is this not the same
>>>>>>>>>> problem as
>>>>>>>>>> ordering modules in the reactor? When there are no dependencies,
>>>>>>>>>> modules
>>>>>>>>>> are built in their specified order, but the order changes when
>>>>>>>>>> there
>>>>>>>>>> are
>>>>>>>>>> dependencies.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> please have a look at the latest comments on MNG-3522, because
>>>>>>>>> adding
>>>>>>>>> executions in a profile causes some edge cases, which should be
>>>>>>>>> defined in
>>>>>>>>> advance.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Jörg
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>> 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
>
> ---------------------------------------------------------------------
> 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: Thoughts on MNG-3522

Posted by Robert Scholte <rf...@apache.org>.

I don't think this is a general use case.

With the same parent, I believe this is a common example:

      <plugin>
        <groupId>com</groupId>
        <artifactId>acme</artifactId>
        <version>2.3</version>
        <executions>
          <execution> <!-- before, because of plugin order -->
            <id>pre</id>
            <phase>...</phase>
            <goals><goal>...</goal></goals>
          </execution>
          <execution dependsOn="foo:bar#munchy">
            <id>post</id>
            <phase>...</phase>
            <goals><goal>...</goal></goals>
          </execution>
        </executions>
      <plugin>

      <plugin>
        <groupId>foo</groupId>
        <artifactId>bar</artifactId>
      <plugin>

In this case you MUST specify the foo:bar plugin as well. Quite a lot of  
tags compared to @before="foo:bar#munchy", but with the same result.
One tricky thing: allowing both @before and @after may cause circular  
executions more often.
Another interesting thing from Igors example: is it allowed to change the  
order of existing/inherited execution blocks?

thanks,
Robert


Op Thu, 12 Jun 2014 22:43:04 +0200 schreef Igor Fedorenko  
<ig...@ifedorenko.com>:

> Consider the following parent pom.xml snippet
>
>     <plugin>
>       <groupId>foo</groupId>
>       <artifactId>bar</artifactId>
>       <version>1</version>
>       <executions>
>         <execution>
>           <id>munchy</id>
>           <phase>...</phase>
>           <goals><goal>...</goal></goals>
>         </execution>
>       </executions>
>     <plugin>
>
> then in the child I believe you can do
>
>     <plugin>
>       <groupId>foo</groupId>
>       <artifactId>bar</artifactId>
>       <version>1</version>
>       <executions>
>         <execution dependsOn="some-other-plugin-execution">
>           <id>munchy</id>
>           <!-- the rest of configuration is inherited from parent -->
>         </execution>
>       </executions>
>     <plugin>
>
> --
> Regards,
> Igor
>
> On 2014-06-12, 16:19, Anders Hammar wrote:
>>> Child modules can add configuration to mojo executions configured in
>>> parent pom. This isn't pretty, but works.
>>>
>>
>> That's not what I had in mind. I was talking about one plugin binding in
>> the parent pom and then a different plugin binding in the child, which  
>> we
>> want to be after the one in the parent. Then only having "dependsOn"
>> wouldn't work in a case where we can't update the parent.
>>
>>
>>> And, to be clear, I am not saying we shouldn't implement before/after
>>> configuration, I think it will be convenient to have both. All I am
>>> saying only one is truly required.
>>
>>
>> Not in the case I describe (I think).
>>
>>
>>>
>>> --
>>> Regards,
>>> Igor
>>>
>>> On 2014-06-12, 2:23, Anders Hammar wrote:
>>>
>>>>
>>>>> Having said that, I think having both "before" and "after" attributes
>>>>> will make configuration easier in some cases, but I still think all
>>>>> ordering can be expressed just with dependsOf (which is the same as
>>>>> "after").
>>>>>
>>>>
>>>>
>>>> Let's say you're not in control of the pom where the plugin binding is
>>>> declared, which you want to add a binding before. Then it is not  
>>>> possible
>>>> to add the "dependsOn". One scenario would be a parent pom you're
>>>> inheriting from.
>>>>
>>>> /Anders
>>>>
>>>>
>>>>
>>>>> --
>>>>> Regards,
>>>>> Igor
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2014-06-11, 15:44, Robert Scholte wrote:
>>>>>
>>>>>   The "dependsOn" would only help if this execution should be done  
>>>>> *after*
>>>>>> another execution. However, I think we also need a solution for the
>>>>>> *before* one, unless we say: just manage this by ordering your  
>>>>>> plugins.
>>>>>> Keep in mind: what to do if executions are defined in the parent  
>>>>>> and you
>>>>>> want to execute your plugin before and/or after these inherited
>>>>>> executions?
>>>>>>
>>>>>> Thanks,
>>>>>> Robert
>>>>>>
>>>>>> Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko
>>>>>> <ig...@ifedorenko.com>:
>>>>>>
>>>>>>    Misconfigured execution order should be reported as build failer.
>>>>>>
>>>>>>>
>>>>>>> I don't see how profiles make this problem more complicated. It  
>>>>>>> maybe
>>>>>>> little tedious to configure, but I believe it is always possible  
>>>>>>> to add
>>>>>>> dependsOn attribute to execution defined elsewhere. So in your  
>>>>>>> example,
>>>>>>> the release profile will need to define execution with id of the  
>>>>>>> "final
>>>>>>> step" and add dependsOf="id-of-sign-step".
>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>> Igor
>>>>>>>
>>>>>>> On 2014-06-11, 15:17, Jörg Schaible wrote:
>>>>>>>
>>>>>>>   Hi Igor,
>>>>>>>>
>>>>>>>> Igor Fedorenko wrote:
>>>>>>>>
>>>>>>>>    More I think about it, less I like the idea of explicit order
>>>>>>>> values. I
>>>>>>>>
>>>>>>>>> think this will be rather inconvenient to setup and error prone  
>>>>>>>>> to
>>>>>>>>> maintain.
>>>>>>>>>
>>>>>>>>> Initial setup will require some tooling to see executions in a
>>>>>>>>> particular case with their default ordering values. Not the end  
>>>>>>>>> of
>>>>>>>>> the
>>>>>>>>> world, but somebody will have to implement the tooling and the  
>>>>>>>>> users
>>>>>>>>> will know how to find it.
>>>>>>>>>
>>>>>>>>> More problematic will be ongoing changes to the project itself
>>>>>>>>> and its parents. When I need to add/remove executions in a  
>>>>>>>>> parent, I
>>>>>>>>> will have to review all projects that inherit from it to ensure
>>>>>>>>> order is
>>>>>>>>> still correct. I work on a monster codebase with 600+ modules  
>>>>>>>>> now, I
>>>>>>>>> just don't see how this is workable.
>>>>>>>>>
>>>>>>>>> If executions are enabled through a profile, especially rarely
>>>>>>>>> activated
>>>>>>>>> profile, configuring expected order becomes really cumbersome.
>>>>>>>>> Think of -Prelease profile, that adds gpg mojo to package  
>>>>>>>>> phase...
>>>>>>>>> good luck troubleshooting why signed jars do not match their gpg
>>>>>>>>> signatures during the release.
>>>>>>>>>
>>>>>>>>> I think we need to find a way to make before/after hints work. I
>>>>>>>>> don't
>>>>>>>>> have a proposal yet, but I wonder, is this not the same problem  
>>>>>>>>> as
>>>>>>>>> ordering modules in the reactor? When there are no dependencies,
>>>>>>>>> modules
>>>>>>>>> are built in their specified order, but the order changes when  
>>>>>>>>> there
>>>>>>>>> are
>>>>>>>>> dependencies.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> please have a look at the latest comments on MNG-3522, because  
>>>>>>>> adding
>>>>>>>> executions in a profile causes some edge cases, which should be
>>>>>>>> defined in
>>>>>>>> advance.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Jörg
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>   ---------------------------------------------------------------------
>>>>> 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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Thoughts on MNG-3522

Posted by Igor Fedorenko <ig...@ifedorenko.com>.

Consider the following parent pom.xml snippet

    <plugin>
      <groupId>foo</groupId>
      <artifactId>bar</artifactId>
      <version>1</version>
      <executions>
        <execution>
          <id>munchy</id>
          <phase>...</phase>
          <goals><goal>...</goal></goals>
        </execution>
      </executions>
    <plugin>

then in the child I believe you can do

    <plugin>
      <groupId>foo</groupId>
      <artifactId>bar</artifactId>
      <version>1</version>
      <executions>
        <execution dependsOn="some-other-plugin-execution">
          <id>munchy</id>
          <!-- the rest of configuration is inherited from parent -->
        </execution>
      </executions>
    <plugin>

--
Regards,
Igor

On 2014-06-12, 16:19, Anders Hammar wrote:
>> Child modules can add configuration to mojo executions configured in
>> parent pom. This isn't pretty, but works.
>>
>
> That's not what I had in mind. I was talking about one plugin binding in
> the parent pom and then a different plugin binding in the child, which we
> want to be after the one in the parent. Then only having "dependsOn"
> wouldn't work in a case where we can't update the parent.
>
>
>> And, to be clear, I am not saying we shouldn't implement before/after
>> configuration, I think it will be convenient to have both. All I am
>> saying only one is truly required.
>
>
> Not in the case I describe (I think).
>
>
>>
>> --
>> Regards,
>> Igor
>>
>> On 2014-06-12, 2:23, Anders Hammar wrote:
>>
>>>
>>>> Having said that, I think having both "before" and "after" attributes
>>>> will make configuration easier in some cases, but I still think all
>>>> ordering can be expressed just with dependsOf (which is the same as
>>>> "after").
>>>>
>>>
>>>
>>> Let's say you're not in control of the pom where the plugin binding is
>>> declared, which you want to add a binding before. Then it is not possible
>>> to add the "dependsOn". One scenario would be a parent pom you're
>>> inheriting from.
>>>
>>> /Anders
>>>
>>>
>>>
>>>> --
>>>> Regards,
>>>> Igor
>>>>
>>>>
>>>>
>>>>
>>>> On 2014-06-11, 15:44, Robert Scholte wrote:
>>>>
>>>>   The "dependsOn" would only help if this execution should be done *after*
>>>>> another execution. However, I think we also need a solution for the
>>>>> *before* one, unless we say: just manage this by ordering your plugins.
>>>>> Keep in mind: what to do if executions are defined in the parent and you
>>>>> want to execute your plugin before and/or after these inherited
>>>>> executions?
>>>>>
>>>>> Thanks,
>>>>> Robert
>>>>>
>>>>> Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko
>>>>> <ig...@ifedorenko.com>:
>>>>>
>>>>>    Misconfigured execution order should be reported as build failer.
>>>>>
>>>>>>
>>>>>> I don't see how profiles make this problem more complicated. It maybe
>>>>>> little tedious to configure, but I believe it is always possible to add
>>>>>> dependsOn attribute to execution defined elsewhere. So in your example,
>>>>>> the release profile will need to define execution with id of the "final
>>>>>> step" and add dependsOf="id-of-sign-step".
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> Igor
>>>>>>
>>>>>> On 2014-06-11, 15:17, Jörg Schaible wrote:
>>>>>>
>>>>>>   Hi Igor,
>>>>>>>
>>>>>>> Igor Fedorenko wrote:
>>>>>>>
>>>>>>>    More I think about it, less I like the idea of explicit order
>>>>>>> values. I
>>>>>>>
>>>>>>>> think this will be rather inconvenient to setup and error prone to
>>>>>>>> maintain.
>>>>>>>>
>>>>>>>> Initial setup will require some tooling to see executions in a
>>>>>>>> particular case with their default ordering values. Not the end of
>>>>>>>> the
>>>>>>>> world, but somebody will have to implement the tooling and the users
>>>>>>>> will know how to find it.
>>>>>>>>
>>>>>>>> More problematic will be ongoing changes to the project itself
>>>>>>>> and its parents. When I need to add/remove executions in a parent, I
>>>>>>>> will have to review all projects that inherit from it to ensure
>>>>>>>> order is
>>>>>>>> still correct. I work on a monster codebase with 600+ modules now, I
>>>>>>>> just don't see how this is workable.
>>>>>>>>
>>>>>>>> If executions are enabled through a profile, especially rarely
>>>>>>>> activated
>>>>>>>> profile, configuring expected order becomes really cumbersome.
>>>>>>>> Think of -Prelease profile, that adds gpg mojo to package phase...
>>>>>>>> good luck troubleshooting why signed jars do not match their gpg
>>>>>>>> signatures during the release.
>>>>>>>>
>>>>>>>> I think we need to find a way to make before/after hints work. I
>>>>>>>> don't
>>>>>>>> have a proposal yet, but I wonder, is this not the same problem as
>>>>>>>> ordering modules in the reactor? When there are no dependencies,
>>>>>>>> modules
>>>>>>>> are built in their specified order, but the order changes when there
>>>>>>>> are
>>>>>>>> dependencies.
>>>>>>>>
>>>>>>>>
>>>>>>> please have a look at the latest comments on MNG-3522, because adding
>>>>>>> executions in a profile causes some edge cases, which should be
>>>>>>> defined in
>>>>>>> advance.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Jörg
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>>
>>>>>
>>>>>   ---------------------------------------------------------------------
>>>> 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: Thoughts on MNG-3522

Posted by Anders Hammar <an...@hammar.net>.

> Child modules can add configuration to mojo executions configured in
> parent pom. This isn't pretty, but works.
>

That's not what I had in mind. I was talking about one plugin binding in
the parent pom and then a different plugin binding in the child, which we
want to be after the one in the parent. Then only having "dependsOn"
wouldn't work in a case where we can't update the parent.


> And, to be clear, I am not saying we shouldn't implement before/after
> configuration, I think it will be convenient to have both. All I am
> saying only one is truly required.


Not in the case I describe (I think).


>
> --
> Regards,
> Igor
>
> On 2014-06-12, 2:23, Anders Hammar wrote:
>
>>
>>> Having said that, I think having both "before" and "after" attributes
>>> will make configuration easier in some cases, but I still think all
>>> ordering can be expressed just with dependsOf (which is the same as
>>> "after").
>>>
>>
>>
>> Let's say you're not in control of the pom where the plugin binding is
>> declared, which you want to add a binding before. Then it is not possible
>> to add the "dependsOn". One scenario would be a parent pom you're
>> inheriting from.
>>
>> /Anders
>>
>>
>>
>>> --
>>> Regards,
>>> Igor
>>>
>>>
>>>
>>>
>>> On 2014-06-11, 15:44, Robert Scholte wrote:
>>>
>>>  The "dependsOn" would only help if this execution should be done *after*
>>>> another execution. However, I think we also need a solution for the
>>>> *before* one, unless we say: just manage this by ordering your plugins.
>>>> Keep in mind: what to do if executions are defined in the parent and you
>>>> want to execute your plugin before and/or after these inherited
>>>> executions?
>>>>
>>>> Thanks,
>>>> Robert
>>>>
>>>> Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko
>>>> <ig...@ifedorenko.com>:
>>>>
>>>>   Misconfigured execution order should be reported as build failer.
>>>>
>>>>>
>>>>> I don't see how profiles make this problem more complicated. It maybe
>>>>> little tedious to configure, but I believe it is always possible to add
>>>>> dependsOn attribute to execution defined elsewhere. So in your example,
>>>>> the release profile will need to define execution with id of the "final
>>>>> step" and add dependsOf="id-of-sign-step".
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Igor
>>>>>
>>>>> On 2014-06-11, 15:17, Jörg Schaible wrote:
>>>>>
>>>>>  Hi Igor,
>>>>>>
>>>>>> Igor Fedorenko wrote:
>>>>>>
>>>>>>   More I think about it, less I like the idea of explicit order
>>>>>> values. I
>>>>>>
>>>>>>> think this will be rather inconvenient to setup and error prone to
>>>>>>> maintain.
>>>>>>>
>>>>>>> Initial setup will require some tooling to see executions in a
>>>>>>> particular case with their default ordering values. Not the end of
>>>>>>> the
>>>>>>> world, but somebody will have to implement the tooling and the users
>>>>>>> will know how to find it.
>>>>>>>
>>>>>>> More problematic will be ongoing changes to the project itself
>>>>>>> and its parents. When I need to add/remove executions in a parent, I
>>>>>>> will have to review all projects that inherit from it to ensure
>>>>>>> order is
>>>>>>> still correct. I work on a monster codebase with 600+ modules now, I
>>>>>>> just don't see how this is workable.
>>>>>>>
>>>>>>> If executions are enabled through a profile, especially rarely
>>>>>>> activated
>>>>>>> profile, configuring expected order becomes really cumbersome.
>>>>>>> Think of -Prelease profile, that adds gpg mojo to package phase...
>>>>>>> good luck troubleshooting why signed jars do not match their gpg
>>>>>>> signatures during the release.
>>>>>>>
>>>>>>> I think we need to find a way to make before/after hints work. I
>>>>>>> don't
>>>>>>> have a proposal yet, but I wonder, is this not the same problem as
>>>>>>> ordering modules in the reactor? When there are no dependencies,
>>>>>>> modules
>>>>>>> are built in their specified order, but the order changes when there
>>>>>>> are
>>>>>>> dependencies.
>>>>>>>
>>>>>>>
>>>>>> please have a look at the latest comments on MNG-3522, because adding
>>>>>> executions in a profile causes some edge cases, which should be
>>>>>> defined in
>>>>>> advance.
>>>>>>
>>>>>> Regards,
>>>>>> Jörg
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>
>>>>
>>>>  ---------------------------------------------------------------------
>>> 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: Thoughts on MNG-3522

Posted by Igor Fedorenko <ig...@ifedorenko.com>.

Child modules can add configuration to mojo executions configured in
parent pom. This isn't pretty, but works.

And, to be clear, I am not saying we shouldn't implement before/after
configuration, I think it will be convenient to have both. All I am
saying only one is truly required.

--
Regards,
Igor

On 2014-06-12, 2:23, Anders Hammar wrote:
>>
>> Having said that, I think having both "before" and "after" attributes
>> will make configuration easier in some cases, but I still think all
>> ordering can be expressed just with dependsOf (which is the same as
>> "after").
>
>
> Let's say you're not in control of the pom where the plugin binding is
> declared, which you want to add a binding before. Then it is not possible
> to add the "dependsOn". One scenario would be a parent pom you're
> inheriting from.
>
> /Anders
>
>
>>
>> --
>> Regards,
>> Igor
>>
>>
>>
>>
>> On 2014-06-11, 15:44, Robert Scholte wrote:
>>
>>> The "dependsOn" would only help if this execution should be done *after*
>>> another execution. However, I think we also need a solution for the
>>> *before* one, unless we say: just manage this by ordering your plugins.
>>> Keep in mind: what to do if executions are defined in the parent and you
>>> want to execute your plugin before and/or after these inherited
>>> executions?
>>>
>>> Thanks,
>>> Robert
>>>
>>> Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko
>>> <ig...@ifedorenko.com>:
>>>
>>>   Misconfigured execution order should be reported as build failer.
>>>>
>>>> I don't see how profiles make this problem more complicated. It maybe
>>>> little tedious to configure, but I believe it is always possible to add
>>>> dependsOn attribute to execution defined elsewhere. So in your example,
>>>> the release profile will need to define execution with id of the "final
>>>> step" and add dependsOf="id-of-sign-step".
>>>>
>>>> --
>>>> Regards,
>>>> Igor
>>>>
>>>> On 2014-06-11, 15:17, Jörg Schaible wrote:
>>>>
>>>>> Hi Igor,
>>>>>
>>>>> Igor Fedorenko wrote:
>>>>>
>>>>>   More I think about it, less I like the idea of explicit order values. I
>>>>>> think this will be rather inconvenient to setup and error prone to
>>>>>> maintain.
>>>>>>
>>>>>> Initial setup will require some tooling to see executions in a
>>>>>> particular case with their default ordering values. Not the end of the
>>>>>> world, but somebody will have to implement the tooling and the users
>>>>>> will know how to find it.
>>>>>>
>>>>>> More problematic will be ongoing changes to the project itself
>>>>>> and its parents. When I need to add/remove executions in a parent, I
>>>>>> will have to review all projects that inherit from it to ensure
>>>>>> order is
>>>>>> still correct. I work on a monster codebase with 600+ modules now, I
>>>>>> just don't see how this is workable.
>>>>>>
>>>>>> If executions are enabled through a profile, especially rarely
>>>>>> activated
>>>>>> profile, configuring expected order becomes really cumbersome.
>>>>>> Think of -Prelease profile, that adds gpg mojo to package phase...
>>>>>> good luck troubleshooting why signed jars do not match their gpg
>>>>>> signatures during the release.
>>>>>>
>>>>>> I think we need to find a way to make before/after hints work. I don't
>>>>>> have a proposal yet, but I wonder, is this not the same problem as
>>>>>> ordering modules in the reactor? When there are no dependencies,
>>>>>> modules
>>>>>> are built in their specified order, but the order changes when there
>>>>>> are
>>>>>> dependencies.
>>>>>>
>>>>>
>>>>> please have a look at the latest comments on MNG-3522, because adding
>>>>> executions in a profile causes some edge cases, which should be
>>>>> defined in
>>>>> advance.
>>>>>
>>>>> Regards,
>>>>> Jörg
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>
>>>
>> ---------------------------------------------------------------------
>> 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: Thoughts on MNG-3522

Posted by Anders Hammar <an...@hammar.net>.

>
> Having said that, I think having both "before" and "after" attributes
> will make configuration easier in some cases, but I still think all
> ordering can be expressed just with dependsOf (which is the same as
> "after").


Let's say you're not in control of the pom where the plugin binding is
declared, which you want to add a binding before. Then it is not possible
to add the "dependsOn". One scenario would be a parent pom you're
inheriting from.

/Anders


>
> --
> Regards,
> Igor
>
>
>
>
> On 2014-06-11, 15:44, Robert Scholte wrote:
>
>> The "dependsOn" would only help if this execution should be done *after*
>> another execution. However, I think we also need a solution for the
>> *before* one, unless we say: just manage this by ordering your plugins.
>> Keep in mind: what to do if executions are defined in the parent and you
>> want to execute your plugin before and/or after these inherited
>> executions?
>>
>> Thanks,
>> Robert
>>
>> Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko
>> <ig...@ifedorenko.com>:
>>
>>  Misconfigured execution order should be reported as build failer.
>>>
>>> I don't see how profiles make this problem more complicated. It maybe
>>> little tedious to configure, but I believe it is always possible to add
>>> dependsOn attribute to execution defined elsewhere. So in your example,
>>> the release profile will need to define execution with id of the "final
>>> step" and add dependsOf="id-of-sign-step".
>>>
>>> --
>>> Regards,
>>> Igor
>>>
>>> On 2014-06-11, 15:17, Jörg Schaible wrote:
>>>
>>>> Hi Igor,
>>>>
>>>> Igor Fedorenko wrote:
>>>>
>>>>  More I think about it, less I like the idea of explicit order values. I
>>>>> think this will be rather inconvenient to setup and error prone to
>>>>> maintain.
>>>>>
>>>>> Initial setup will require some tooling to see executions in a
>>>>> particular case with their default ordering values. Not the end of the
>>>>> world, but somebody will have to implement the tooling and the users
>>>>> will know how to find it.
>>>>>
>>>>> More problematic will be ongoing changes to the project itself
>>>>> and its parents. When I need to add/remove executions in a parent, I
>>>>> will have to review all projects that inherit from it to ensure
>>>>> order is
>>>>> still correct. I work on a monster codebase with 600+ modules now, I
>>>>> just don't see how this is workable.
>>>>>
>>>>> If executions are enabled through a profile, especially rarely
>>>>> activated
>>>>> profile, configuring expected order becomes really cumbersome.
>>>>> Think of -Prelease profile, that adds gpg mojo to package phase...
>>>>> good luck troubleshooting why signed jars do not match their gpg
>>>>> signatures during the release.
>>>>>
>>>>> I think we need to find a way to make before/after hints work. I don't
>>>>> have a proposal yet, but I wonder, is this not the same problem as
>>>>> ordering modules in the reactor? When there are no dependencies,
>>>>> modules
>>>>> are built in their specified order, but the order changes when there
>>>>> are
>>>>> dependencies.
>>>>>
>>>>
>>>> please have a look at the latest comments on MNG-3522, because adding
>>>> executions in a profile causes some edge cases, which should be
>>>> defined in
>>>> advance.
>>>>
>>>> Regards,
>>>> Jörg
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Thoughts on MNG-3522

Posted by Igor Fedorenko <ig...@ifedorenko.com>.

It is possible to "amend" inherited execution configuration, maven will
use plugin GA and execution id to merge the configuration, and I assume
it will or at least can merge dependsOn attribute.

Having said that, I think having both "before" and "after" attributes
will make configuration easier in some cases, but I still think all
ordering can be expressed just with dependsOf (which is the same as
"after").

--
Regards,
Igor



On 2014-06-11, 15:44, Robert Scholte wrote:
> The "dependsOn" would only help if this execution should be done *after*
> another execution. However, I think we also need a solution for the
> *before* one, unless we say: just manage this by ordering your plugins.
> Keep in mind: what to do if executions are defined in the parent and you
> want to execute your plugin before and/or after these inherited executions?
>
> Thanks,
> Robert
>
> Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko
> <ig...@ifedorenko.com>:
>
>> Misconfigured execution order should be reported as build failer.
>>
>> I don't see how profiles make this problem more complicated. It maybe
>> little tedious to configure, but I believe it is always possible to add
>> dependsOn attribute to execution defined elsewhere. So in your example,
>> the release profile will need to define execution with id of the "final
>> step" and add dependsOf="id-of-sign-step".
>>
>> --
>> Regards,
>> Igor
>>
>> On 2014-06-11, 15:17, Jörg Schaible wrote:
>>> Hi Igor,
>>>
>>> Igor Fedorenko wrote:
>>>
>>>> More I think about it, less I like the idea of explicit order values. I
>>>> think this will be rather inconvenient to setup and error prone to
>>>> maintain.
>>>>
>>>> Initial setup will require some tooling to see executions in a
>>>> particular case with their default ordering values. Not the end of the
>>>> world, but somebody will have to implement the tooling and the users
>>>> will know how to find it.
>>>>
>>>> More problematic will be ongoing changes to the project itself
>>>> and its parents. When I need to add/remove executions in a parent, I
>>>> will have to review all projects that inherit from it to ensure
>>>> order is
>>>> still correct. I work on a monster codebase with 600+ modules now, I
>>>> just don't see how this is workable.
>>>>
>>>> If executions are enabled through a profile, especially rarely
>>>> activated
>>>> profile, configuring expected order becomes really cumbersome.
>>>> Think of -Prelease profile, that adds gpg mojo to package phase...
>>>> good luck troubleshooting why signed jars do not match their gpg
>>>> signatures during the release.
>>>>
>>>> I think we need to find a way to make before/after hints work. I don't
>>>> have a proposal yet, but I wonder, is this not the same problem as
>>>> ordering modules in the reactor? When there are no dependencies,
>>>> modules
>>>> are built in their specified order, but the order changes when there
>>>> are
>>>> dependencies.
>>>
>>> please have a look at the latest comments on MNG-3522, because adding
>>> executions in a profile causes some edge cases, which should be
>>> defined in
>>> advance.
>>>
>>> Regards,
>>> Jörg
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Thoughts on MNG-3522

Posted by Paul Benedict <pb...@apache.org>.

FWIW, in my use of Spring Security, I am able to place a security check
within a security filter chain using a "before" or "after" attribute. It
makes relative positioning very easy.


Cheers,
Paul


On Wed, Jun 11, 2014 at 2:44 PM, Robert Scholte <rf...@apache.org>
wrote:

> The "dependsOn" would only help if this execution should be done *after*
> another execution. However, I think we also need a solution for the
> *before* one, unless we say: just manage this by ordering your plugins.
> Keep in mind: what to do if executions are defined in the parent and you
> want to execute your plugin before and/or after these inherited executions?
>
> Thanks,
> Robert
>
> Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko <
> igor@ifedorenko.com>:
>
>
>  Misconfigured execution order should be reported as build failer.
>>
>> I don't see how profiles make this problem more complicated. It maybe
>> little tedious to configure, but I believe it is always possible to add
>> dependsOn attribute to execution defined elsewhere. So in your example,
>> the release profile will need to define execution with id of the "final
>> step" and add dependsOf="id-of-sign-step".
>>
>> --
>> Regards,
>> Igor
>>
>> On 2014-06-11, 15:17, Jörg Schaible wrote:
>>
>>> Hi Igor,
>>>
>>> Igor Fedorenko wrote:
>>>
>>>  More I think about it, less I like the idea of explicit order values. I
>>>> think this will be rather inconvenient to setup and error prone to
>>>> maintain.
>>>>
>>>> Initial setup will require some tooling to see executions in a
>>>> particular case with their default ordering values. Not the end of the
>>>> world, but somebody will have to implement the tooling and the users
>>>> will know how to find it.
>>>>
>>>> More problematic will be ongoing changes to the project itself
>>>> and its parents. When I need to add/remove executions in a parent, I
>>>> will have to review all projects that inherit from it to ensure order is
>>>> still correct. I work on a monster codebase with 600+ modules now, I
>>>> just don't see how this is workable.
>>>>
>>>> If executions are enabled through a profile, especially rarely activated
>>>> profile, configuring expected order becomes really cumbersome.
>>>> Think of -Prelease profile, that adds gpg mojo to package phase...
>>>> good luck troubleshooting why signed jars do not match their gpg
>>>> signatures during the release.
>>>>
>>>> I think we need to find a way to make before/after hints work. I don't
>>>> have a proposal yet, but I wonder, is this not the same problem as
>>>> ordering modules in the reactor? When there are no dependencies, modules
>>>> are built in their specified order, but the order changes when there are
>>>> dependencies.
>>>>
>>>
>>> please have a look at the latest comments on MNG-3522, because adding
>>> executions in a profile causes some edge cases, which should be defined
>>> in
>>> advance.
>>>
>>> Regards,
>>> Jörg
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: Thoughts on MNG-3522

Posted by Robert Scholte <rf...@apache.org>.

The "dependsOn" would only help if this execution should be done *after*  
another execution. However, I think we also need a solution for the  
*before* one, unless we say: just manage this by ordering your plugins.
Keep in mind: what to do if executions are defined in the parent and you  
want to execute your plugin before and/or after these inherited executions?

Thanks,
Robert

Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko  
<ig...@ifedorenko.com>:

> Misconfigured execution order should be reported as build failer.
>
> I don't see how profiles make this problem more complicated. It maybe
> little tedious to configure, but I believe it is always possible to add
> dependsOn attribute to execution defined elsewhere. So in your example,
> the release profile will need to define execution with id of the "final
> step" and add dependsOf="id-of-sign-step".
>
> --
> Regards,
> Igor
>
> On 2014-06-11, 15:17, Jörg Schaible wrote:
>> Hi Igor,
>>
>> Igor Fedorenko wrote:
>>
>>> More I think about it, less I like the idea of explicit order values. I
>>> think this will be rather inconvenient to setup and error prone to
>>> maintain.
>>>
>>> Initial setup will require some tooling to see executions in a
>>> particular case with their default ordering values. Not the end of the
>>> world, but somebody will have to implement the tooling and the users
>>> will know how to find it.
>>>
>>> More problematic will be ongoing changes to the project itself
>>> and its parents. When I need to add/remove executions in a parent, I
>>> will have to review all projects that inherit from it to ensure order  
>>> is
>>> still correct. I work on a monster codebase with 600+ modules now, I
>>> just don't see how this is workable.
>>>
>>> If executions are enabled through a profile, especially rarely  
>>> activated
>>> profile, configuring expected order becomes really cumbersome.
>>> Think of -Prelease profile, that adds gpg mojo to package phase...
>>> good luck troubleshooting why signed jars do not match their gpg
>>> signatures during the release.
>>>
>>> I think we need to find a way to make before/after hints work. I don't
>>> have a proposal yet, but I wonder, is this not the same problem as
>>> ordering modules in the reactor? When there are no dependencies,  
>>> modules
>>> are built in their specified order, but the order changes when there  
>>> are
>>> dependencies.
>>
>> please have a look at the latest comments on MNG-3522, because adding
>> executions in a profile causes some edge cases, which should be defined  
>> in
>> advance.
>>
>> Regards,
>> Jörg
>>
>>
>> ---------------------------------------------------------------------
>> 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: Thoughts on MNG-3522

Posted by Igor Fedorenko <ig...@ifedorenko.com>.

Misconfigured execution order should be reported as build failer.

I don't see how profiles make this problem more complicated. It maybe
little tedious to configure, but I believe it is always possible to add
dependsOn attribute to execution defined elsewhere. So in your example,
the release profile will need to define execution with id of the "final
step" and add dependsOf="id-of-sign-step".

--
Regards,
Igor

On 2014-06-11, 15:17, Jörg Schaible wrote:
> Hi Igor,
>
> Igor Fedorenko wrote:
>
>> More I think about it, less I like the idea of explicit order values. I
>> think this will be rather inconvenient to setup and error prone to
>> maintain.
>>
>> Initial setup will require some tooling to see executions in a
>> particular case with their default ordering values. Not the end of the
>> world, but somebody will have to implement the tooling and the users
>> will know how to find it.
>>
>> More problematic will be ongoing changes to the project itself
>> and its parents. When I need to add/remove executions in a parent, I
>> will have to review all projects that inherit from it to ensure order is
>> still correct. I work on a monster codebase with 600+ modules now, I
>> just don't see how this is workable.
>>
>> If executions are enabled through a profile, especially rarely activated
>> profile, configuring expected order becomes really cumbersome.
>> Think of -Prelease profile, that adds gpg mojo to package phase...
>> good luck troubleshooting why signed jars do not match their gpg
>> signatures during the release.
>>
>> I think we need to find a way to make before/after hints work. I don't
>> have a proposal yet, but I wonder, is this not the same problem as
>> ordering modules in the reactor? When there are no dependencies, modules
>> are built in their specified order, but the order changes when there are
>> dependencies.
>
> please have a look at the latest comments on MNG-3522, because adding
> executions in a profile causes some edge cases, which should be defined in
> advance.
>
> Regards,
> Jörg
>
>
> ---------------------------------------------------------------------
> 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: Thoughts on MNG-3522

Posted by Jörg Schaible <jo...@gmx.de>.

Hi Igor,

Igor Fedorenko wrote:

> More I think about it, less I like the idea of explicit order values. I
> think this will be rather inconvenient to setup and error prone to
> maintain.
> 
> Initial setup will require some tooling to see executions in a
> particular case with their default ordering values. Not the end of the
> world, but somebody will have to implement the tooling and the users
> will know how to find it.
> 
> More problematic will be ongoing changes to the project itself
> and its parents. When I need to add/remove executions in a parent, I
> will have to review all projects that inherit from it to ensure order is
> still correct. I work on a monster codebase with 600+ modules now, I
> just don't see how this is workable.
> 
> If executions are enabled through a profile, especially rarely activated
> profile, configuring expected order becomes really cumbersome.
> Think of -Prelease profile, that adds gpg mojo to package phase...
> good luck troubleshooting why signed jars do not match their gpg
> signatures during the release.
> 
> I think we need to find a way to make before/after hints work. I don't
> have a proposal yet, but I wonder, is this not the same problem as
> ordering modules in the reactor? When there are no dependencies, modules
> are built in their specified order, but the order changes when there are
> dependencies.

please have a look at the latest comments on MNG-3522, because adding 
executions in a profile causes some edge cases, which should be defined in 
advance.

Regards,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Thoughts on MNG-3522

Posted by Igor Fedorenko <ig...@ifedorenko.com>.

More I think about it, less I like the idea of explicit order values. I
think this will be rather inconvenient to setup and error prone to
maintain.

Initial setup will require some tooling to see executions in a
particular case with their default ordering values. Not the end of the
world, but somebody will have to implement the tooling and the users
will know how to find it.

More problematic will be ongoing changes to the project itself
and its parents. When I need to add/remove executions in a parent, I
will have to review all projects that inherit from it to ensure order is
still correct. I work on a monster codebase with 600+ modules now, I
just don't see how this is workable.

If executions are enabled through a profile, especially rarely activated
profile, configuring expected order becomes really cumbersome.
Think of -Prelease profile, that adds gpg mojo to package phase...
good luck troubleshooting why signed jars do not match their gpg
signatures during the release.

I think we need to find a way to make before/after hints work. I don't
have a proposal yet, but I wonder, is this not the same problem as
ordering modules in the reactor? When there are no dependencies, modules
are built in their specified order, but the order changes when there are
dependencies.

--
Regards,
Igor

On 2014-06-05, 11:11, Paul Benedict wrote:
> Igor, I can come up with three possible solutions which one I prefer.
>
> 1) Unspecified order plugins are all given highest precedence; specified
> plugins come after.
> 2) Unspecified order plugins are all given lowest precedence; specified
> plugins come before.
> 3) Unspecified order plugins are given a default precedence in steps of 100
> (ordered by declaration); specified plugins can be before, middle, after by
> choosing the appropriate number.
>
> I like #3. In your example, I would assign jarsigner precedence value 150
> to fit between pack200:normalize and pack200:goal.
>
>
>
>
> Cheers,
> Paul
>
>
> On Thu, Jun 5, 2014 at 9:38 AM, Paul Benedict <pb...@apache.org> wrote:
>
>> Good question. I haven't thought of that. In all the examples presented
>> thus far, the developer had control over all the <id> executions and
>> explicitly ordered them. This won't be the case all the time. What happens
>> when you mix ordering and unspecified?
>>
>>
>> Cheers,
>> Paul
>>
>>
>> On Thu, Jun 5, 2014 at 9:12 AM, Igor Fedorenko <ig...@ifedorenko.com>
>> wrote:
>>
>>> Mojo executions bound to in packaging type lifecycle mapping have fixed
>>> "default-<goal>" ids. To continue my Tycho pack200 example, I will need
>>> to insert jarsigner between pack200:normalize and pack200:pack goals.
>>> If pack200:normalize and pack200:pack goals are bound to the default
>>> lifecycle, can you explain how to achieve desired execution order with
>>> <id>s?
>>>
>>> --
>>> Regards,
>>> Igor
>>>
>>>
>>> On 2014-06-05, 9:52, Paul Benedict wrote:
>>>
>>>> After giving it some more thought, I think interpolating the <id> is less
>>>> disruptive than a new attribute. I am sure once POM 5 exists, there will
>>>> be
>>>> an official way.
>>>>
>>>> Lastly, I am not not a fan of the "step-#" naming because it's a prefix
>>>> but
>>>> it is more descriptive; I would prefer to just simply allow the developer
>>>> to suffix with a -# (dash number). Thoughts on which nomenclature is
>>>> better?
>>>>
>>>>
>>>> Cheers,
>>>> Paul
>>>>
>>>>
>>>> On Wed, Jun 4, 2014 at 10:59 AM, Igor Fedorenko <ig...@ifedorenko.com>
>>>> wrote:
>>>>
>>>>   I am not sure xml attributes are necessary a hack. Whether to put
>>>>> before/after hints into xml element or attribute is really a matter of
>>>>> taste, imho.
>>>>>
>>>>> I don't want to restart the whole "pom v 5" discussion again, but I was
>>>>> under impression we agreed to preserve format published to maven
>>>>> repository but allow changes in the format used during the build. Which
>>>>> I believe implies that entire <build> section (or whaterver pom 5 will
>>>>> end up using to represent build configuration) will be stripped out of
>>>>> pom.xml files before they are deployed.
>>>>>
>>>>> So I think it is okay to use xml attributes to represent before/after
>>>>> hints today and we can decide to change this to something else when we
>>>>> get to pom 5.
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Igor
>>>>>
>>>>>
>>>>> On 2014-06-04, 11:39, Paul Benedict wrote:
>>>>>
>>>>>   Thanks for your reply Jason.
>>>>>>
>>>>>> So it seems there are some possibilities for this ticket: either
>>>>>> interpreting the <id> to infer order (the patch) or stuffing this into
>>>>>> an
>>>>>> attribute (per Igor). Regarding the latter, the attribute route is
>>>>>> clearly
>>>>>> to avoid adding a new POM element, but aren't both a bit "hackish"? The
>>>>>> desired solution, I think, would be to make this a POM element, but
>>>>>> past
>>>>>> discussions inform me that's clearly off the table.
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Paul
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 4, 2014 at 10:20 AM, Jason van Zyl <ja...@takari.io>
>>>>>> wrote:
>>>>>>
>>>>>>    I'm opposed to random creation of a DAG for executions across all the
>>>>>>
>>>>>>> phases. This just creates a giant mess. That said _within_ a given
>>>>>>> phase
>>>>>>> if
>>>>>>> there was a topological sorting of executions where one execution can
>>>>>>> state
>>>>>>> that it depends on another I think is reasonable. Definitive ordering
>>>>>>> within a phase, I think, is useful.
>>>>>>>
>>>>>>> On Jun 4, 2014, at 10:22 AM, Paul Benedict <pb...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>    I find that solution interesting because, in a way, it kind of
>>>>>>> returns
>>>>>>>
>>>>>>>> us
>>>>>>>> to the days of Maven 1.x where you can run things pre/post goal. I am
>>>>>>>> pretty sure Jason wanted to get rid of that perspective with this 2.x
>>>>>>>> design, but maybe things are coming full circle?
>>>>>>>>
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Paul
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko <ig...@ifedorenko.com>
>>>>>>>>
>>>>>>>>   wrote:
>>>>>>>
>>>>>>>
>>>>>>>>    Yes, I was also thinking before/after as a way to solve this. We
>>>>>>>> can
>>>>>>>>
>>>>>>>>> probably use xml attributes without breaking compat with artifact
>>>>>>>>> consumers, so I think this can be done in Maven 3.x.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Regards,
>>>>>>>>> Igor
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2014-06-04, 10:09, Robert Scholte wrote:
>>>>>>>>>
>>>>>>>>>    Hi Paul,
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> that's my understanding as well.
>>>>>>>>>> But even in a single pom you can have issues.
>>>>>>>>>> Consider 2 plugins, with both 2 goals and you want to run it like
>>>>>>>>>>
>>>>>>>>>> (phase=pre-integration-test)
>>>>>>>>>> pluginA:preSomething
>>>>>>>>>> pluginB:preStuff
>>>>>>>>>>
>>>>>>>>>> (phase=post-integration-test)
>>>>>>>>>> pluginB:postStuff
>>>>>>>>>> pluginA:postSomething
>>>>>>>>>>
>>>>>>>>>> Since plugins should be unique within the build-section, it's not
>>>>>>>>>> possible to have a clean solution for this.
>>>>>>>>>>
>>>>>>>>>> Instead of the step-X solution of MNG-4727 I think you should be
>>>>>>>>>> able
>>>>>>>>>>
>>>>>>>>>>   to
>>>>>>>>>
>>>>>>>>
>>>>>>>   run it before or after a specified goal.
>>>>>>>>
>>>>>>>>> We could think of using a convention for the execution-id, or
>>>>>>>>>> define a
>>>>>>>>>> new element in the pom-5.0.0
>>>>>>>>>>
>>>>>>>>>> thanks,
>>>>>>>>>>
>>>>>>>>>> Robert
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict
>>>>>>>>>> <pb...@apache.org>:
>>>>>>>>>>
>>>>>>>>>> Anyone have thoughts on this ticket? There is a submitted patch, as
>>>>>>>>>> the
>>>>>>>>>>
>>>>>>>>>>   last comment says -- it's part of another ticket that was marked
>>>>>>>>>>> as
>>>>>>>>>>> duplicate.
>>>>>>>>>>>
>>>>>>>>>>> Though, I am a bit confused. I thought plugin execution was
>>>>>>>>>>> already
>>>>>>>>>>> defined
>>>>>>>>>>> by the sequential order listed in the POM. Am I incorrect? If so,
>>>>>>>>>>> I
>>>>>>>>>>>
>>>>>>>>>>>   still
>>>>>>>>>>
>>>>>>>>>
>>>>>>>   don't know if that's "good enough" when using POM inheritance.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Paul
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>   ------------------------------------------------------------
>>>>>>>>>> ---------
>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   Thanks,
>>>>>>>
>>>>>>> Jason
>>>>>>>
>>>>>>> ----------------------------------------------------------
>>>>>>> Jason van Zyl
>>>>>>> Founder,  Apache Maven
>>>>>>> http://twitter.com/jvanzyl
>>>>>>> http://twitter.com/takari_io
>>>>>>> ---------------------------------------------------------
>>>>>>>
>>>>>>> A language that doesn’t affect the way you think about programming is
>>>>>>> not
>>>>>>> worth knowing.
>>>>>>>
>>>>>>>     -- Alan Perlis
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>   ---------------------------------------------------------------------
>>>>> 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: Thoughts on MNG-3522

Posted by Paul Benedict <pb...@apache.org>.

Igor, I can come up with three possible solutions which one I prefer.

1) Unspecified order plugins are all given highest precedence; specified
plugins come after.
2) Unspecified order plugins are all given lowest precedence; specified
plugins come before.
3) Unspecified order plugins are given a default precedence in steps of 100
(ordered by declaration); specified plugins can be before, middle, after by
choosing the appropriate number.

I like #3. In your example, I would assign jarsigner precedence value 150
to fit between pack200:normalize and pack200:goal.




Cheers,
Paul


On Thu, Jun 5, 2014 at 9:38 AM, Paul Benedict <pb...@apache.org> wrote:

> Good question. I haven't thought of that. In all the examples presented
> thus far, the developer had control over all the <id> executions and
> explicitly ordered them. This won't be the case all the time. What happens
> when you mix ordering and unspecified?
>
>
> Cheers,
> Paul
>
>
> On Thu, Jun 5, 2014 at 9:12 AM, Igor Fedorenko <ig...@ifedorenko.com>
> wrote:
>
>> Mojo executions bound to in packaging type lifecycle mapping have fixed
>> "default-<goal>" ids. To continue my Tycho pack200 example, I will need
>> to insert jarsigner between pack200:normalize and pack200:pack goals.
>> If pack200:normalize and pack200:pack goals are bound to the default
>> lifecycle, can you explain how to achieve desired execution order with
>> <id>s?
>>
>> --
>> Regards,
>> Igor
>>
>>
>> On 2014-06-05, 9:52, Paul Benedict wrote:
>>
>>> After giving it some more thought, I think interpolating the <id> is less
>>> disruptive than a new attribute. I am sure once POM 5 exists, there will
>>> be
>>> an official way.
>>>
>>> Lastly, I am not not a fan of the "step-#" naming because it's a prefix
>>> but
>>> it is more descriptive; I would prefer to just simply allow the developer
>>> to suffix with a -# (dash number). Thoughts on which nomenclature is
>>> better?
>>>
>>>
>>> Cheers,
>>> Paul
>>>
>>>
>>> On Wed, Jun 4, 2014 at 10:59 AM, Igor Fedorenko <ig...@ifedorenko.com>
>>> wrote:
>>>
>>>  I am not sure xml attributes are necessary a hack. Whether to put
>>>> before/after hints into xml element or attribute is really a matter of
>>>> taste, imho.
>>>>
>>>> I don't want to restart the whole "pom v 5" discussion again, but I was
>>>> under impression we agreed to preserve format published to maven
>>>> repository but allow changes in the format used during the build. Which
>>>> I believe implies that entire <build> section (or whaterver pom 5 will
>>>> end up using to represent build configuration) will be stripped out of
>>>> pom.xml files before they are deployed.
>>>>
>>>> So I think it is okay to use xml attributes to represent before/after
>>>> hints today and we can decide to change this to something else when we
>>>> get to pom 5.
>>>>
>>>> --
>>>> Regards,
>>>> Igor
>>>>
>>>>
>>>> On 2014-06-04, 11:39, Paul Benedict wrote:
>>>>
>>>>  Thanks for your reply Jason.
>>>>>
>>>>> So it seems there are some possibilities for this ticket: either
>>>>> interpreting the <id> to infer order (the patch) or stuffing this into
>>>>> an
>>>>> attribute (per Igor). Regarding the latter, the attribute route is
>>>>> clearly
>>>>> to avoid adding a new POM element, but aren't both a bit "hackish"? The
>>>>> desired solution, I think, would be to make this a POM element, but
>>>>> past
>>>>> discussions inform me that's clearly off the table.
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Paul
>>>>>
>>>>>
>>>>> On Wed, Jun 4, 2014 at 10:20 AM, Jason van Zyl <ja...@takari.io>
>>>>> wrote:
>>>>>
>>>>>   I'm opposed to random creation of a DAG for executions across all the
>>>>>
>>>>>> phases. This just creates a giant mess. That said _within_ a given
>>>>>> phase
>>>>>> if
>>>>>> there was a topological sorting of executions where one execution can
>>>>>> state
>>>>>> that it depends on another I think is reasonable. Definitive ordering
>>>>>> within a phase, I think, is useful.
>>>>>>
>>>>>> On Jun 4, 2014, at 10:22 AM, Paul Benedict <pb...@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>>   I find that solution interesting because, in a way, it kind of
>>>>>> returns
>>>>>>
>>>>>>> us
>>>>>>> to the days of Maven 1.x where you can run things pre/post goal. I am
>>>>>>> pretty sure Jason wanted to get rid of that perspective with this 2.x
>>>>>>> design, but maybe things are coming full circle?
>>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Paul
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko <ig...@ifedorenko.com>
>>>>>>>
>>>>>>>  wrote:
>>>>>>
>>>>>>
>>>>>>>   Yes, I was also thinking before/after as a way to solve this. We
>>>>>>> can
>>>>>>>
>>>>>>>> probably use xml attributes without breaking compat with artifact
>>>>>>>> consumers, so I think this can be done in Maven 3.x.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Regards,
>>>>>>>> Igor
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2014-06-04, 10:09, Robert Scholte wrote:
>>>>>>>>
>>>>>>>>   Hi Paul,
>>>>>>>>
>>>>>>>>>
>>>>>>>>> that's my understanding as well.
>>>>>>>>> But even in a single pom you can have issues.
>>>>>>>>> Consider 2 plugins, with both 2 goals and you want to run it like
>>>>>>>>>
>>>>>>>>> (phase=pre-integration-test)
>>>>>>>>> pluginA:preSomething
>>>>>>>>> pluginB:preStuff
>>>>>>>>>
>>>>>>>>> (phase=post-integration-test)
>>>>>>>>> pluginB:postStuff
>>>>>>>>> pluginA:postSomething
>>>>>>>>>
>>>>>>>>> Since plugins should be unique within the build-section, it's not
>>>>>>>>> possible to have a clean solution for this.
>>>>>>>>>
>>>>>>>>> Instead of the step-X solution of MNG-4727 I think you should be
>>>>>>>>> able
>>>>>>>>>
>>>>>>>>>  to
>>>>>>>>
>>>>>>>
>>>>>>  run it before or after a specified goal.
>>>>>>>
>>>>>>>> We could think of using a convention for the execution-id, or
>>>>>>>>> define a
>>>>>>>>> new element in the pom-5.0.0
>>>>>>>>>
>>>>>>>>> thanks,
>>>>>>>>>
>>>>>>>>> Robert
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict
>>>>>>>>> <pb...@apache.org>:
>>>>>>>>>
>>>>>>>>> Anyone have thoughts on this ticket? There is a submitted patch, as
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>>  last comment says -- it's part of another ticket that was marked
>>>>>>>>>> as
>>>>>>>>>> duplicate.
>>>>>>>>>>
>>>>>>>>>> Though, I am a bit confused. I thought plugin execution was
>>>>>>>>>> already
>>>>>>>>>> defined
>>>>>>>>>> by the sequential order listed in the POM. Am I incorrect? If so,
>>>>>>>>>> I
>>>>>>>>>>
>>>>>>>>>>  still
>>>>>>>>>
>>>>>>>>
>>>>>>  don't know if that's "good enough" when using POM inheritance.
>>>>>>>
>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Paul
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  ------------------------------------------------------------
>>>>>>>>> ---------
>>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>  Thanks,
>>>>>>
>>>>>> Jason
>>>>>>
>>>>>> ----------------------------------------------------------
>>>>>> Jason van Zyl
>>>>>> Founder,  Apache Maven
>>>>>> http://twitter.com/jvanzyl
>>>>>> http://twitter.com/takari_io
>>>>>> ---------------------------------------------------------
>>>>>>
>>>>>> A language that doesn’t affect the way you think about programming is
>>>>>> not
>>>>>> worth knowing.
>>>>>>
>>>>>>    -- Alan Perlis
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>  ---------------------------------------------------------------------
>>>> 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: Thoughts on MNG-3522

Posted by Paul Benedict <pb...@apache.org>.

Good question. I haven't thought of that. In all the examples presented
thus far, the developer had control over all the <id> executions and
explicitly ordered them. This won't be the case all the time. What happens
when you mix ordering and unspecified?


Cheers,
Paul


On Thu, Jun 5, 2014 at 9:12 AM, Igor Fedorenko <ig...@ifedorenko.com> wrote:

> Mojo executions bound to in packaging type lifecycle mapping have fixed
> "default-<goal>" ids. To continue my Tycho pack200 example, I will need
> to insert jarsigner between pack200:normalize and pack200:pack goals.
> If pack200:normalize and pack200:pack goals are bound to the default
> lifecycle, can you explain how to achieve desired execution order with
> <id>s?
>
> --
> Regards,
> Igor
>
>
> On 2014-06-05, 9:52, Paul Benedict wrote:
>
>> After giving it some more thought, I think interpolating the <id> is less
>> disruptive than a new attribute. I am sure once POM 5 exists, there will
>> be
>> an official way.
>>
>> Lastly, I am not not a fan of the "step-#" naming because it's a prefix
>> but
>> it is more descriptive; I would prefer to just simply allow the developer
>> to suffix with a -# (dash number). Thoughts on which nomenclature is
>> better?
>>
>>
>> Cheers,
>> Paul
>>
>>
>> On Wed, Jun 4, 2014 at 10:59 AM, Igor Fedorenko <ig...@ifedorenko.com>
>> wrote:
>>
>>  I am not sure xml attributes are necessary a hack. Whether to put
>>> before/after hints into xml element or attribute is really a matter of
>>> taste, imho.
>>>
>>> I don't want to restart the whole "pom v 5" discussion again, but I was
>>> under impression we agreed to preserve format published to maven
>>> repository but allow changes in the format used during the build. Which
>>> I believe implies that entire <build> section (or whaterver pom 5 will
>>> end up using to represent build configuration) will be stripped out of
>>> pom.xml files before they are deployed.
>>>
>>> So I think it is okay to use xml attributes to represent before/after
>>> hints today and we can decide to change this to something else when we
>>> get to pom 5.
>>>
>>> --
>>> Regards,
>>> Igor
>>>
>>>
>>> On 2014-06-04, 11:39, Paul Benedict wrote:
>>>
>>>  Thanks for your reply Jason.
>>>>
>>>> So it seems there are some possibilities for this ticket: either
>>>> interpreting the <id> to infer order (the patch) or stuffing this into
>>>> an
>>>> attribute (per Igor). Regarding the latter, the attribute route is
>>>> clearly
>>>> to avoid adding a new POM element, but aren't both a bit "hackish"? The
>>>> desired solution, I think, would be to make this a POM element, but past
>>>> discussions inform me that's clearly off the table.
>>>>
>>>>
>>>> Cheers,
>>>> Paul
>>>>
>>>>
>>>> On Wed, Jun 4, 2014 at 10:20 AM, Jason van Zyl <ja...@takari.io> wrote:
>>>>
>>>>   I'm opposed to random creation of a DAG for executions across all the
>>>>
>>>>> phases. This just creates a giant mess. That said _within_ a given
>>>>> phase
>>>>> if
>>>>> there was a topological sorting of executions where one execution can
>>>>> state
>>>>> that it depends on another I think is reasonable. Definitive ordering
>>>>> within a phase, I think, is useful.
>>>>>
>>>>> On Jun 4, 2014, at 10:22 AM, Paul Benedict <pb...@apache.org>
>>>>> wrote:
>>>>>
>>>>>   I find that solution interesting because, in a way, it kind of
>>>>> returns
>>>>>
>>>>>> us
>>>>>> to the days of Maven 1.x where you can run things pre/post goal. I am
>>>>>> pretty sure Jason wanted to get rid of that perspective with this 2.x
>>>>>> design, but maybe things are coming full circle?
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Paul
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko <ig...@ifedorenko.com>
>>>>>>
>>>>>>  wrote:
>>>>>
>>>>>
>>>>>>   Yes, I was also thinking before/after as a way to solve this. We can
>>>>>>
>>>>>>> probably use xml attributes without breaking compat with artifact
>>>>>>> consumers, so I think this can be done in Maven 3.x.
>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>> Igor
>>>>>>>
>>>>>>>
>>>>>>> On 2014-06-04, 10:09, Robert Scholte wrote:
>>>>>>>
>>>>>>>   Hi Paul,
>>>>>>>
>>>>>>>>
>>>>>>>> that's my understanding as well.
>>>>>>>> But even in a single pom you can have issues.
>>>>>>>> Consider 2 plugins, with both 2 goals and you want to run it like
>>>>>>>>
>>>>>>>> (phase=pre-integration-test)
>>>>>>>> pluginA:preSomething
>>>>>>>> pluginB:preStuff
>>>>>>>>
>>>>>>>> (phase=post-integration-test)
>>>>>>>> pluginB:postStuff
>>>>>>>> pluginA:postSomething
>>>>>>>>
>>>>>>>> Since plugins should be unique within the build-section, it's not
>>>>>>>> possible to have a clean solution for this.
>>>>>>>>
>>>>>>>> Instead of the step-X solution of MNG-4727 I think you should be
>>>>>>>> able
>>>>>>>>
>>>>>>>>  to
>>>>>>>
>>>>>>
>>>>>  run it before or after a specified goal.
>>>>>>
>>>>>>> We could think of using a convention for the execution-id, or define
>>>>>>>> a
>>>>>>>> new element in the pom-5.0.0
>>>>>>>>
>>>>>>>> thanks,
>>>>>>>>
>>>>>>>> Robert
>>>>>>>>
>>>>>>>>
>>>>>>>> Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict
>>>>>>>> <pb...@apache.org>:
>>>>>>>>
>>>>>>>> Anyone have thoughts on this ticket? There is a submitted patch, as
>>>>>>>> the
>>>>>>>>
>>>>>>>>  last comment says -- it's part of another ticket that was marked as
>>>>>>>>> duplicate.
>>>>>>>>>
>>>>>>>>> Though, I am a bit confused. I thought plugin execution was already
>>>>>>>>> defined
>>>>>>>>> by the sequential order listed in the POM. Am I incorrect? If so, I
>>>>>>>>>
>>>>>>>>>  still
>>>>>>>>
>>>>>>>
>>>>>  don't know if that's "good enough" when using POM inheritance.
>>>>>>
>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Paul
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  ------------------------------------------------------------
>>>>>>>> ---------
>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  Thanks,
>>>>>
>>>>> Jason
>>>>>
>>>>> ----------------------------------------------------------
>>>>> Jason van Zyl
>>>>> Founder,  Apache Maven
>>>>> http://twitter.com/jvanzyl
>>>>> http://twitter.com/takari_io
>>>>> ---------------------------------------------------------
>>>>>
>>>>> A language that doesn’t affect the way you think about programming is
>>>>> not
>>>>> worth knowing.
>>>>>
>>>>>    -- Alan Perlis
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>  ---------------------------------------------------------------------
>>> 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: Thoughts on MNG-3522

Posted by Igor Fedorenko <ig...@ifedorenko.com>.

Mojo executions bound to in packaging type lifecycle mapping have fixed
"default-<goal>" ids. To continue my Tycho pack200 example, I will need
to insert jarsigner between pack200:normalize and pack200:pack goals.
If pack200:normalize and pack200:pack goals are bound to the default
lifecycle, can you explain how to achieve desired execution order with
<id>s?

--
Regards,
Igor

On 2014-06-05, 9:52, Paul Benedict wrote:
> After giving it some more thought, I think interpolating the <id> is less
> disruptive than a new attribute. I am sure once POM 5 exists, there will be
> an official way.
>
> Lastly, I am not not a fan of the "step-#" naming because it's a prefix but
> it is more descriptive; I would prefer to just simply allow the developer
> to suffix with a -# (dash number). Thoughts on which nomenclature is better?
>
>
> Cheers,
> Paul
>
>
> On Wed, Jun 4, 2014 at 10:59 AM, Igor Fedorenko <ig...@ifedorenko.com> wrote:
>
>> I am not sure xml attributes are necessary a hack. Whether to put
>> before/after hints into xml element or attribute is really a matter of
>> taste, imho.
>>
>> I don't want to restart the whole "pom v 5" discussion again, but I was
>> under impression we agreed to preserve format published to maven
>> repository but allow changes in the format used during the build. Which
>> I believe implies that entire <build> section (or whaterver pom 5 will
>> end up using to represent build configuration) will be stripped out of
>> pom.xml files before they are deployed.
>>
>> So I think it is okay to use xml attributes to represent before/after
>> hints today and we can decide to change this to something else when we
>> get to pom 5.
>>
>> --
>> Regards,
>> Igor
>>
>>
>> On 2014-06-04, 11:39, Paul Benedict wrote:
>>
>>> Thanks for your reply Jason.
>>>
>>> So it seems there are some possibilities for this ticket: either
>>> interpreting the <id> to infer order (the patch) or stuffing this into an
>>> attribute (per Igor). Regarding the latter, the attribute route is clearly
>>> to avoid adding a new POM element, but aren't both a bit "hackish"? The
>>> desired solution, I think, would be to make this a POM element, but past
>>> discussions inform me that's clearly off the table.
>>>
>>>
>>> Cheers,
>>> Paul
>>>
>>>
>>> On Wed, Jun 4, 2014 at 10:20 AM, Jason van Zyl <ja...@takari.io> wrote:
>>>
>>>   I'm opposed to random creation of a DAG for executions across all the
>>>> phases. This just creates a giant mess. That said _within_ a given phase
>>>> if
>>>> there was a topological sorting of executions where one execution can
>>>> state
>>>> that it depends on another I think is reasonable. Definitive ordering
>>>> within a phase, I think, is useful.
>>>>
>>>> On Jun 4, 2014, at 10:22 AM, Paul Benedict <pb...@apache.org> wrote:
>>>>
>>>>   I find that solution interesting because, in a way, it kind of returns
>>>>> us
>>>>> to the days of Maven 1.x where you can run things pre/post goal. I am
>>>>> pretty sure Jason wanted to get rid of that perspective with this 2.x
>>>>> design, but maybe things are coming full circle?
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Paul
>>>>>
>>>>>
>>>>> On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko <ig...@ifedorenko.com>
>>>>>
>>>> wrote:
>>>>
>>>>>
>>>>>   Yes, I was also thinking before/after as a way to solve this. We can
>>>>>> probably use xml attributes without breaking compat with artifact
>>>>>> consumers, so I think this can be done in Maven 3.x.
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> Igor
>>>>>>
>>>>>>
>>>>>> On 2014-06-04, 10:09, Robert Scholte wrote:
>>>>>>
>>>>>>   Hi Paul,
>>>>>>>
>>>>>>> that's my understanding as well.
>>>>>>> But even in a single pom you can have issues.
>>>>>>> Consider 2 plugins, with both 2 goals and you want to run it like
>>>>>>>
>>>>>>> (phase=pre-integration-test)
>>>>>>> pluginA:preSomething
>>>>>>> pluginB:preStuff
>>>>>>>
>>>>>>> (phase=post-integration-test)
>>>>>>> pluginB:postStuff
>>>>>>> pluginA:postSomething
>>>>>>>
>>>>>>> Since plugins should be unique within the build-section, it's not
>>>>>>> possible to have a clean solution for this.
>>>>>>>
>>>>>>> Instead of the step-X solution of MNG-4727 I think you should be able
>>>>>>>
>>>>>> to
>>>>
>>>>> run it before or after a specified goal.
>>>>>>> We could think of using a convention for the execution-id, or define a
>>>>>>> new element in the pom-5.0.0
>>>>>>>
>>>>>>> thanks,
>>>>>>>
>>>>>>> Robert
>>>>>>>
>>>>>>>
>>>>>>> Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict
>>>>>>> <pb...@apache.org>:
>>>>>>>
>>>>>>> Anyone have thoughts on this ticket? There is a submitted patch, as
>>>>>>> the
>>>>>>>
>>>>>>>> last comment says -- it's part of another ticket that was marked as
>>>>>>>> duplicate.
>>>>>>>>
>>>>>>>> Though, I am a bit confused. I thought plugin execution was already
>>>>>>>> defined
>>>>>>>> by the sequential order listed in the POM. Am I incorrect? If so, I
>>>>>>>>
>>>>>>> still
>>>>
>>>>> don't know if that's "good enough" when using POM inheritance.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Paul
>>>>>>>>
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>> Thanks,
>>>>
>>>> Jason
>>>>
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder,  Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> http://twitter.com/takari_io
>>>> ---------------------------------------------------------
>>>>
>>>> A language that doesn’t affect the way you think about programming is not
>>>> worth knowing.
>>>>
>>>>    -- Alan Perlis
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> 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: Thoughts on MNG-3522

Posted by Jason van Zyl <ja...@takari.io>.

I actually think the attributes are perfectly fine and won't interfere with anything. The attributes were always intended to be metadata about the elements and I think the use of instructing the core about how to order the executions falls into that category of use.

On Jun 5, 2014, at 9:52 AM, Paul Benedict <pb...@apache.org> wrote:

> After giving it some more thought, I think interpolating the <id> is less
> disruptive than a new attribute. I am sure once POM 5 exists, there will be
> an official way.
> 
> Lastly, I am not not a fan of the "step-#" naming because it's a prefix but
> it is more descriptive; I would prefer to just simply allow the developer
> to suffix with a -# (dash number). Thoughts on which nomenclature is better?
> 
> 
> Cheers,
> Paul
> 
> 
> On Wed, Jun 4, 2014 at 10:59 AM, Igor Fedorenko <ig...@ifedorenko.com> wrote:
> 
>> I am not sure xml attributes are necessary a hack. Whether to put
>> before/after hints into xml element or attribute is really a matter of
>> taste, imho.
>> 
>> I don't want to restart the whole "pom v 5" discussion again, but I was
>> under impression we agreed to preserve format published to maven
>> repository but allow changes in the format used during the build. Which
>> I believe implies that entire <build> section (or whaterver pom 5 will
>> end up using to represent build configuration) will be stripped out of
>> pom.xml files before they are deployed.
>> 
>> So I think it is okay to use xml attributes to represent before/after
>> hints today and we can decide to change this to something else when we
>> get to pom 5.
>> 
>> --
>> Regards,
>> Igor
>> 
>> 
>> On 2014-06-04, 11:39, Paul Benedict wrote:
>> 
>>> Thanks for your reply Jason.
>>> 
>>> So it seems there are some possibilities for this ticket: either
>>> interpreting the <id> to infer order (the patch) or stuffing this into an
>>> attribute (per Igor). Regarding the latter, the attribute route is clearly
>>> to avoid adding a new POM element, but aren't both a bit "hackish"? The
>>> desired solution, I think, would be to make this a POM element, but past
>>> discussions inform me that's clearly off the table.
>>> 
>>> 
>>> Cheers,
>>> Paul
>>> 
>>> 
>>> On Wed, Jun 4, 2014 at 10:20 AM, Jason van Zyl <ja...@takari.io> wrote:
>>> 
>>> I'm opposed to random creation of a DAG for executions across all the
>>>> phases. This just creates a giant mess. That said _within_ a given phase
>>>> if
>>>> there was a topological sorting of executions where one execution can
>>>> state
>>>> that it depends on another I think is reasonable. Definitive ordering
>>>> within a phase, I think, is useful.
>>>> 
>>>> On Jun 4, 2014, at 10:22 AM, Paul Benedict <pb...@apache.org> wrote:
>>>> 
>>>> I find that solution interesting because, in a way, it kind of returns
>>>>> us
>>>>> to the days of Maven 1.x where you can run things pre/post goal. I am
>>>>> pretty sure Jason wanted to get rid of that perspective with this 2.x
>>>>> design, but maybe things are coming full circle?
>>>>> 
>>>>> 
>>>>> Cheers,
>>>>> Paul
>>>>> 
>>>>> 
>>>>> On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko <ig...@ifedorenko.com>
>>>>> 
>>>> wrote:
>>>> 
>>>>> 
>>>>> Yes, I was also thinking before/after as a way to solve this. We can
>>>>>> probably use xml attributes without breaking compat with artifact
>>>>>> consumers, so I think this can be done in Maven 3.x.
>>>>>> 
>>>>>> --
>>>>>> Regards,
>>>>>> Igor
>>>>>> 
>>>>>> 
>>>>>> On 2014-06-04, 10:09, Robert Scholte wrote:
>>>>>> 
>>>>>> Hi Paul,
>>>>>>> 
>>>>>>> that's my understanding as well.
>>>>>>> But even in a single pom you can have issues.
>>>>>>> Consider 2 plugins, with both 2 goals and you want to run it like
>>>>>>> 
>>>>>>> (phase=pre-integration-test)
>>>>>>> pluginA:preSomething
>>>>>>> pluginB:preStuff
>>>>>>> 
>>>>>>> (phase=post-integration-test)
>>>>>>> pluginB:postStuff
>>>>>>> pluginA:postSomething
>>>>>>> 
>>>>>>> Since plugins should be unique within the build-section, it's not
>>>>>>> possible to have a clean solution for this.
>>>>>>> 
>>>>>>> Instead of the step-X solution of MNG-4727 I think you should be able
>>>>>>> 
>>>>>> to
>>>> 
>>>>> run it before or after a specified goal.
>>>>>>> We could think of using a convention for the execution-id, or define a
>>>>>>> new element in the pom-5.0.0
>>>>>>> 
>>>>>>> thanks,
>>>>>>> 
>>>>>>> Robert
>>>>>>> 
>>>>>>> 
>>>>>>> Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict
>>>>>>> <pb...@apache.org>:
>>>>>>> 
>>>>>>> Anyone have thoughts on this ticket? There is a submitted patch, as
>>>>>>> the
>>>>>>> 
>>>>>>>> last comment says -- it's part of another ticket that was marked as
>>>>>>>> duplicate.
>>>>>>>> 
>>>>>>>> Though, I am a bit confused. I thought plugin execution was already
>>>>>>>> defined
>>>>>>>> by the sequential order listed in the POM. Am I incorrect? If so, I
>>>>>>>> 
>>>>>>> still
>>>> 
>>>>> don't know if that's "good enough" when using POM inheritance.
>>>>>>>> 
>>>>>>>> Cheers,
>>>>>>>> Paul
>>>>>>>> 
>>>>>>>> 
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>>> 
>>>>>> 
>>>>>> 
>>>> Thanks,
>>>> 
>>>> Jason
>>>> 
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder,  Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> http://twitter.com/takari_io
>>>> ---------------------------------------------------------
>>>> 
>>>> A language that doesn’t affect the way you think about programming is not
>>>> worth knowing.
>>>> 
>>>>  -- Alan Perlis
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
>> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.

  -- Jacques Ellul, The Technological Society

Re: Thoughts on MNG-3522

Posted by Paul Benedict <pb...@apache.org>.

After giving it some more thought, I think interpolating the <id> is less
disruptive than a new attribute. I am sure once POM 5 exists, there will be
an official way.

Lastly, I am not not a fan of the "step-#" naming because it's a prefix but
it is more descriptive; I would prefer to just simply allow the developer
to suffix with a -# (dash number). Thoughts on which nomenclature is better?


Cheers,
Paul


On Wed, Jun 4, 2014 at 10:59 AM, Igor Fedorenko <ig...@ifedorenko.com> wrote:

> I am not sure xml attributes are necessary a hack. Whether to put
> before/after hints into xml element or attribute is really a matter of
> taste, imho.
>
> I don't want to restart the whole "pom v 5" discussion again, but I was
> under impression we agreed to preserve format published to maven
> repository but allow changes in the format used during the build. Which
> I believe implies that entire <build> section (or whaterver pom 5 will
> end up using to represent build configuration) will be stripped out of
> pom.xml files before they are deployed.
>
> So I think it is okay to use xml attributes to represent before/after
> hints today and we can decide to change this to something else when we
> get to pom 5.
>
> --
> Regards,
> Igor
>
>
> On 2014-06-04, 11:39, Paul Benedict wrote:
>
>> Thanks for your reply Jason.
>>
>> So it seems there are some possibilities for this ticket: either
>> interpreting the <id> to infer order (the patch) or stuffing this into an
>> attribute (per Igor). Regarding the latter, the attribute route is clearly
>> to avoid adding a new POM element, but aren't both a bit "hackish"? The
>> desired solution, I think, would be to make this a POM element, but past
>> discussions inform me that's clearly off the table.
>>
>>
>> Cheers,
>> Paul
>>
>>
>> On Wed, Jun 4, 2014 at 10:20 AM, Jason van Zyl <ja...@takari.io> wrote:
>>
>>  I'm opposed to random creation of a DAG for executions across all the
>>> phases. This just creates a giant mess. That said _within_ a given phase
>>> if
>>> there was a topological sorting of executions where one execution can
>>> state
>>> that it depends on another I think is reasonable. Definitive ordering
>>> within a phase, I think, is useful.
>>>
>>> On Jun 4, 2014, at 10:22 AM, Paul Benedict <pb...@apache.org> wrote:
>>>
>>>  I find that solution interesting because, in a way, it kind of returns
>>>> us
>>>> to the days of Maven 1.x where you can run things pre/post goal. I am
>>>> pretty sure Jason wanted to get rid of that perspective with this 2.x
>>>> design, but maybe things are coming full circle?
>>>>
>>>>
>>>> Cheers,
>>>> Paul
>>>>
>>>>
>>>> On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko <ig...@ifedorenko.com>
>>>>
>>> wrote:
>>>
>>>>
>>>>  Yes, I was also thinking before/after as a way to solve this. We can
>>>>> probably use xml attributes without breaking compat with artifact
>>>>> consumers, so I think this can be done in Maven 3.x.
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Igor
>>>>>
>>>>>
>>>>> On 2014-06-04, 10:09, Robert Scholte wrote:
>>>>>
>>>>>  Hi Paul,
>>>>>>
>>>>>> that's my understanding as well.
>>>>>> But even in a single pom you can have issues.
>>>>>> Consider 2 plugins, with both 2 goals and you want to run it like
>>>>>>
>>>>>> (phase=pre-integration-test)
>>>>>> pluginA:preSomething
>>>>>> pluginB:preStuff
>>>>>>
>>>>>> (phase=post-integration-test)
>>>>>> pluginB:postStuff
>>>>>> pluginA:postSomething
>>>>>>
>>>>>> Since plugins should be unique within the build-section, it's not
>>>>>> possible to have a clean solution for this.
>>>>>>
>>>>>> Instead of the step-X solution of MNG-4727 I think you should be able
>>>>>>
>>>>> to
>>>
>>>> run it before or after a specified goal.
>>>>>> We could think of using a convention for the execution-id, or define a
>>>>>> new element in the pom-5.0.0
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> Robert
>>>>>>
>>>>>>
>>>>>> Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict
>>>>>> <pb...@apache.org>:
>>>>>>
>>>>>> Anyone have thoughts on this ticket? There is a submitted patch, as
>>>>>> the
>>>>>>
>>>>>>> last comment says -- it's part of another ticket that was marked as
>>>>>>> duplicate.
>>>>>>>
>>>>>>> Though, I am a bit confused. I thought plugin execution was already
>>>>>>> defined
>>>>>>> by the sequential order listed in the POM. Am I incorrect? If so, I
>>>>>>>
>>>>>> still
>>>
>>>> don't know if that's "good enough" when using POM inheritance.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Paul
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>>>
>>>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder,  Apache Maven
>>> http://twitter.com/jvanzyl
>>> http://twitter.com/takari_io
>>> ---------------------------------------------------------
>>>
>>> A language that doesn’t affect the way you think about programming is not
>>> worth knowing.
>>>
>>>   -- Alan Perlis
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Thoughts on MNG-3522

Posted by Igor Fedorenko <ig...@ifedorenko.com>.

I am not sure xml attributes are necessary a hack. Whether to put
before/after hints into xml element or attribute is really a matter of
taste, imho.

I don't want to restart the whole "pom v 5" discussion again, but I was
under impression we agreed to preserve format published to maven
repository but allow changes in the format used during the build. Which
I believe implies that entire <build> section (or whaterver pom 5 will
end up using to represent build configuration) will be stripped out of
pom.xml files before they are deployed.

So I think it is okay to use xml attributes to represent before/after
hints today and we can decide to change this to something else when we
get to pom 5.

--
Regards,
Igor

On 2014-06-04, 11:39, Paul Benedict wrote:
> Thanks for your reply Jason.
>
> So it seems there are some possibilities for this ticket: either
> interpreting the <id> to infer order (the patch) or stuffing this into an
> attribute (per Igor). Regarding the latter, the attribute route is clearly
> to avoid adding a new POM element, but aren't both a bit "hackish"? The
> desired solution, I think, would be to make this a POM element, but past
> discussions inform me that's clearly off the table.
>
>
> Cheers,
> Paul
>
>
> On Wed, Jun 4, 2014 at 10:20 AM, Jason van Zyl <ja...@takari.io> wrote:
>
>> I'm opposed to random creation of a DAG for executions across all the
>> phases. This just creates a giant mess. That said _within_ a given phase if
>> there was a topological sorting of executions where one execution can state
>> that it depends on another I think is reasonable. Definitive ordering
>> within a phase, I think, is useful.
>>
>> On Jun 4, 2014, at 10:22 AM, Paul Benedict <pb...@apache.org> wrote:
>>
>>> I find that solution interesting because, in a way, it kind of returns us
>>> to the days of Maven 1.x where you can run things pre/post goal. I am
>>> pretty sure Jason wanted to get rid of that perspective with this 2.x
>>> design, but maybe things are coming full circle?
>>>
>>>
>>> Cheers,
>>> Paul
>>>
>>>
>>> On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko <ig...@ifedorenko.com>
>> wrote:
>>>
>>>> Yes, I was also thinking before/after as a way to solve this. We can
>>>> probably use xml attributes without breaking compat with artifact
>>>> consumers, so I think this can be done in Maven 3.x.
>>>>
>>>> --
>>>> Regards,
>>>> Igor
>>>>
>>>>
>>>> On 2014-06-04, 10:09, Robert Scholte wrote:
>>>>
>>>>> Hi Paul,
>>>>>
>>>>> that's my understanding as well.
>>>>> But even in a single pom you can have issues.
>>>>> Consider 2 plugins, with both 2 goals and you want to run it like
>>>>>
>>>>> (phase=pre-integration-test)
>>>>> pluginA:preSomething
>>>>> pluginB:preStuff
>>>>>
>>>>> (phase=post-integration-test)
>>>>> pluginB:postStuff
>>>>> pluginA:postSomething
>>>>>
>>>>> Since plugins should be unique within the build-section, it's not
>>>>> possible to have a clean solution for this.
>>>>>
>>>>> Instead of the step-X solution of MNG-4727 I think you should be able
>> to
>>>>> run it before or after a specified goal.
>>>>> We could think of using a convention for the execution-id, or define a
>>>>> new element in the pom-5.0.0
>>>>>
>>>>> thanks,
>>>>>
>>>>> Robert
>>>>>
>>>>>
>>>>> Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict
>>>>> <pb...@apache.org>:
>>>>>
>>>>> Anyone have thoughts on this ticket? There is a submitted patch, as the
>>>>>> last comment says -- it's part of another ticket that was marked as
>>>>>> duplicate.
>>>>>>
>>>>>> Though, I am a bit confused. I thought plugin execution was already
>>>>>> defined
>>>>>> by the sequential order listed in the POM. Am I incorrect? If so, I
>> still
>>>>>> don't know if that's "good enough" when using POM inheritance.
>>>>>>
>>>>>> Cheers,
>>>>>> Paul
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> ---------------------------------------------------------
>>
>> A language that doesn’t affect the way you think about programming is not
>> worth knowing.
>>
>>   -- Alan Perlis
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Thoughts on MNG-3522

Posted by Paul Benedict <pb...@apache.org>.

Thanks for your reply Jason.

So it seems there are some possibilities for this ticket: either
interpreting the <id> to infer order (the patch) or stuffing this into an
attribute (per Igor). Regarding the latter, the attribute route is clearly
to avoid adding a new POM element, but aren't both a bit "hackish"? The
desired solution, I think, would be to make this a POM element, but past
discussions inform me that's clearly off the table.


Cheers,
Paul


On Wed, Jun 4, 2014 at 10:20 AM, Jason van Zyl <ja...@takari.io> wrote:

> I'm opposed to random creation of a DAG for executions across all the
> phases. This just creates a giant mess. That said _within_ a given phase if
> there was a topological sorting of executions where one execution can state
> that it depends on another I think is reasonable. Definitive ordering
> within a phase, I think, is useful.
>
> On Jun 4, 2014, at 10:22 AM, Paul Benedict <pb...@apache.org> wrote:
>
> > I find that solution interesting because, in a way, it kind of returns us
> > to the days of Maven 1.x where you can run things pre/post goal. I am
> > pretty sure Jason wanted to get rid of that perspective with this 2.x
> > design, but maybe things are coming full circle?
> >
> >
> > Cheers,
> > Paul
> >
> >
> > On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko <ig...@ifedorenko.com>
> wrote:
> >
> >> Yes, I was also thinking before/after as a way to solve this. We can
> >> probably use xml attributes without breaking compat with artifact
> >> consumers, so I think this can be done in Maven 3.x.
> >>
> >> --
> >> Regards,
> >> Igor
> >>
> >>
> >> On 2014-06-04, 10:09, Robert Scholte wrote:
> >>
> >>> Hi Paul,
> >>>
> >>> that's my understanding as well.
> >>> But even in a single pom you can have issues.
> >>> Consider 2 plugins, with both 2 goals and you want to run it like
> >>>
> >>> (phase=pre-integration-test)
> >>> pluginA:preSomething
> >>> pluginB:preStuff
> >>>
> >>> (phase=post-integration-test)
> >>> pluginB:postStuff
> >>> pluginA:postSomething
> >>>
> >>> Since plugins should be unique within the build-section, it's not
> >>> possible to have a clean solution for this.
> >>>
> >>> Instead of the step-X solution of MNG-4727 I think you should be able
> to
> >>> run it before or after a specified goal.
> >>> We could think of using a convention for the execution-id, or define a
> >>> new element in the pom-5.0.0
> >>>
> >>> thanks,
> >>>
> >>> Robert
> >>>
> >>>
> >>> Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict
> >>> <pb...@apache.org>:
> >>>
> >>> Anyone have thoughts on this ticket? There is a submitted patch, as the
> >>>> last comment says -- it's part of another ticket that was marked as
> >>>> duplicate.
> >>>>
> >>>> Though, I am a bit confused. I thought plugin execution was already
> >>>> defined
> >>>> by the sequential order listed in the POM. Am I incorrect? If so, I
> still
> >>>> don't know if that's "good enough" when using POM inheritance.
> >>>>
> >>>> Cheers,
> >>>> Paul
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
> >>
> >>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
> A language that doesn’t affect the way you think about programming is not
> worth knowing.
>
>  -- Alan Perlis
>
>
>
>
>
>
>
>
>
>

Re: Thoughts on MNG-3522

Posted by Jason van Zyl <ja...@takari.io>.

I'm opposed to random creation of a DAG for executions across all the phases. This just creates a giant mess. That said _within_ a given phase if there was a topological sorting of executions where one execution can state that it depends on another I think is reasonable. Definitive ordering within a phase, I think, is useful.

On Jun 4, 2014, at 10:22 AM, Paul Benedict <pb...@apache.org> wrote:

> I find that solution interesting because, in a way, it kind of returns us
> to the days of Maven 1.x where you can run things pre/post goal. I am
> pretty sure Jason wanted to get rid of that perspective with this 2.x
> design, but maybe things are coming full circle?
> 
> 
> Cheers,
> Paul
> 
> 
> On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko <ig...@ifedorenko.com> wrote:
> 
>> Yes, I was also thinking before/after as a way to solve this. We can
>> probably use xml attributes without breaking compat with artifact
>> consumers, so I think this can be done in Maven 3.x.
>> 
>> --
>> Regards,
>> Igor
>> 
>> 
>> On 2014-06-04, 10:09, Robert Scholte wrote:
>> 
>>> Hi Paul,
>>> 
>>> that's my understanding as well.
>>> But even in a single pom you can have issues.
>>> Consider 2 plugins, with both 2 goals and you want to run it like
>>> 
>>> (phase=pre-integration-test)
>>> pluginA:preSomething
>>> pluginB:preStuff
>>> 
>>> (phase=post-integration-test)
>>> pluginB:postStuff
>>> pluginA:postSomething
>>> 
>>> Since plugins should be unique within the build-section, it's not
>>> possible to have a clean solution for this.
>>> 
>>> Instead of the step-X solution of MNG-4727 I think you should be able to
>>> run it before or after a specified goal.
>>> We could think of using a convention for the execution-id, or define a
>>> new element in the pom-5.0.0
>>> 
>>> thanks,
>>> 
>>> Robert
>>> 
>>> 
>>> Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict
>>> <pb...@apache.org>:
>>> 
>>> Anyone have thoughts on this ticket? There is a submitted patch, as the
>>>> last comment says -- it's part of another ticket that was marked as
>>>> duplicate.
>>>> 
>>>> Though, I am a bit confused. I thought plugin execution was already
>>>> defined
>>>> by the sequential order listed in the POM. Am I incorrect? If so, I still
>>>> don't know if that's "good enough" when using POM inheritance.
>>>> 
>>>> Cheers,
>>>> Paul
>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> 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
>> 
>> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------

A language that doesn’t affect the way you think about programming is not worth knowing. 
 
 -- Alan Perlis

Re: Thoughts on MNG-3522

Posted by Igor Fedorenko <ig...@ifedorenko.com>.

Maven 1.x was before my time :-) Can somebody recap the reasons ordering
executions within a phase was decided harmful?

--
Regards,
Igor

On 2014-06-04, 10:22, Paul Benedict wrote:
> I find that solution interesting because, in a way, it kind of returns us
> to the days of Maven 1.x where you can run things pre/post goal. I am
> pretty sure Jason wanted to get rid of that perspective with this 2.x
> design, but maybe things are coming full circle?
>
>
> Cheers,
> Paul
>
>
> On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko <ig...@ifedorenko.com> wrote:
>
>> Yes, I was also thinking before/after as a way to solve this. We can
>> probably use xml attributes without breaking compat with artifact
>> consumers, so I think this can be done in Maven 3.x.
>>
>> --
>> Regards,
>> Igor
>>
>>
>> On 2014-06-04, 10:09, Robert Scholte wrote:
>>
>>> Hi Paul,
>>>
>>> that's my understanding as well.
>>> But even in a single pom you can have issues.
>>> Consider 2 plugins, with both 2 goals and you want to run it like
>>>
>>> (phase=pre-integration-test)
>>> pluginA:preSomething
>>> pluginB:preStuff
>>>
>>> (phase=post-integration-test)
>>> pluginB:postStuff
>>> pluginA:postSomething
>>>
>>> Since plugins should be unique within the build-section, it's not
>>> possible to have a clean solution for this.
>>>
>>> Instead of the step-X solution of MNG-4727 I think you should be able to
>>> run it before or after a specified goal.
>>> We could think of using a convention for the execution-id, or define a
>>> new element in the pom-5.0.0
>>>
>>> thanks,
>>>
>>> Robert
>>>
>>>
>>> Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict
>>> <pb...@apache.org>:
>>>
>>>   Anyone have thoughts on this ticket? There is a submitted patch, as the
>>>> last comment says -- it's part of another ticket that was marked as
>>>> duplicate.
>>>>
>>>> Though, I am a bit confused. I thought plugin execution was already
>>>> defined
>>>> by the sequential order listed in the POM. Am I incorrect? If so, I still
>>>> don't know if that's "good enough" when using POM inheritance.
>>>>
>>>> Cheers,
>>>> Paul
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: Thoughts on MNG-3522

Posted by Paul Benedict <pb...@apache.org>.

I find that solution interesting because, in a way, it kind of returns us
to the days of Maven 1.x where you can run things pre/post goal. I am
pretty sure Jason wanted to get rid of that perspective with this 2.x
design, but maybe things are coming full circle?


Cheers,
Paul


On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko <ig...@ifedorenko.com> wrote:

> Yes, I was also thinking before/after as a way to solve this. We can
> probably use xml attributes without breaking compat with artifact
> consumers, so I think this can be done in Maven 3.x.
>
> --
> Regards,
> Igor
>
>
> On 2014-06-04, 10:09, Robert Scholte wrote:
>
>> Hi Paul,
>>
>> that's my understanding as well.
>> But even in a single pom you can have issues.
>> Consider 2 plugins, with both 2 goals and you want to run it like
>>
>> (phase=pre-integration-test)
>> pluginA:preSomething
>> pluginB:preStuff
>>
>> (phase=post-integration-test)
>> pluginB:postStuff
>> pluginA:postSomething
>>
>> Since plugins should be unique within the build-section, it's not
>> possible to have a clean solution for this.
>>
>> Instead of the step-X solution of MNG-4727 I think you should be able to
>> run it before or after a specified goal.
>> We could think of using a convention for the execution-id, or define a
>> new element in the pom-5.0.0
>>
>> thanks,
>>
>> Robert
>>
>>
>> Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict
>> <pb...@apache.org>:
>>
>>  Anyone have thoughts on this ticket? There is a submitted patch, as the
>>> last comment says -- it's part of another ticket that was marked as
>>> duplicate.
>>>
>>> Though, I am a bit confused. I thought plugin execution was already
>>> defined
>>> by the sequential order listed in the POM. Am I incorrect? If so, I still
>>> don't know if that's "good enough" when using POM inheritance.
>>>
>>> Cheers,
>>> Paul
>>>
>>
>> ---------------------------------------------------------------------
>> 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: Thoughts on MNG-3522

Posted by Igor Fedorenko <ig...@ifedorenko.com>.

Yes, I was also thinking before/after as a way to solve this. We can
probably use xml attributes without breaking compat with artifact
consumers, so I think this can be done in Maven 3.x.

--
Regards,
Igor

On 2014-06-04, 10:09, Robert Scholte wrote:
> Hi Paul,
>
> that's my understanding as well.
> But even in a single pom you can have issues.
> Consider 2 plugins, with both 2 goals and you want to run it like
>
> (phase=pre-integration-test)
> pluginA:preSomething
> pluginB:preStuff
>
> (phase=post-integration-test)
> pluginB:postStuff
> pluginA:postSomething
>
> Since plugins should be unique within the build-section, it's not
> possible to have a clean solution for this.
>
> Instead of the step-X solution of MNG-4727 I think you should be able to
> run it before or after a specified goal.
> We could think of using a convention for the execution-id, or define a
> new element in the pom-5.0.0
>
> thanks,
>
> Robert
>
>
> Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict
> <pb...@apache.org>:
>
>> Anyone have thoughts on this ticket? There is a submitted patch, as the
>> last comment says -- it's part of another ticket that was marked as
>> duplicate.
>>
>> Though, I am a bit confused. I thought plugin execution was already
>> defined
>> by the sequential order listed in the POM. Am I incorrect? If so, I still
>> don't know if that's "good enough" when using POM inheritance.
>>
>> Cheers,
>> Paul
>
> ---------------------------------------------------------------------
> 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: Thoughts on MNG-3522

Posted by Robert Scholte <rf...@apache.org>.

Hi Paul,

that's my understanding as well.
But even in a single pom you can have issues.
Consider 2 plugins, with both 2 goals and you want to run it like

(phase=pre-integration-test)
pluginA:preSomething
pluginB:preStuff

(phase=post-integration-test)
pluginB:postStuff
pluginA:postSomething

Since plugins should be unique within the build-section, it's not possible  
to have a clean solution for this.

Instead of the step-X solution of MNG-4727 I think you should be able to  
run it before or after a specified goal.
We could think of using a convention for the execution-id, or define a new  
element in the pom-5.0.0

thanks,

Robert


Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict  
<pb...@apache.org>:

> Anyone have thoughts on this ticket? There is a submitted patch, as the
> last comment says -- it's part of another ticket that was marked as
> duplicate.
>
> Though, I am a bit confused. I thought plugin execution was already  
> defined
> by the sequential order listed in the POM. Am I incorrect? If so, I still
> don't know if that's "good enough" when using POM inheritance.
>
> Cheers,
> Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org