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 <i...@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 <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
> >>>>
> >>>>
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > 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
> ---------------------------------------------------------
>
> 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)
>
>
>
>
>
>
>
>
>
>
