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

Reply via email to