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)
