maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Benedict <pbened...@apache.org>
Subject Re: Thoughts on MNG-3522
Date Thu, 05 Jun 2014 15:11:41 GMT
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 <pbenedict@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 <igor@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 <jason@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 <pbenedict@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
>>>>>>>>> <pbenedict@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
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message