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 <pbened...@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 <i...@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 <i...@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 <pbened...@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 <i...@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 >>>>>>>>> <pbened...@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-unsubscr...@maven.apache.org >>>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------------------ >>>>>>>>> >>>>>>>> --------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@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-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>>> >>>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> >
