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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> >>>>>> 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 >>>>>>>> <[email protected]>: >>>>>>>> >>>>>>>> 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: [email protected] >>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------ >>>>>>>> >>>>>>> --------- >>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
