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

Reply via email to