Having said that, I think having both before and after attributes
will make configuration easier in some cases, but I still think all
ordering can be expressed just with dependsOf (which is the same as
after).
Let's say you're not in control of the pom where the plugin binding is
declared,
Child modules can add configuration to mojo executions configured in
parent pom. This isn't pretty, but works.
And, to be clear, I am not saying we shouldn't implement before/after
configuration, I think it will be convenient to have both. All I am
saying only one is truly required.
--
Regards,
Child modules can add configuration to mojo executions configured in
parent pom. This isn't pretty, but works.
That's not what I had in mind. I was talking about one plugin binding in
the parent pom and then a different plugin binding in the child, which we
want to be after the one in the
Consider the following parent pom.xml snippet
plugin
groupIdfoo/groupId
artifactIdbar/artifactId
version1/version
executions
execution
idmunchy/id
phase.../phase
goalsgoal.../goal/goals
/execution
/executions
plugin
then in
Sorry, my bad. I meant the binding in the child to be BEFORE the one on the
parent. I can't alter the declaration in the parent in my scenario as I'm
not on control of it.
/Anders (mobile)
Den 12 jun 2014 22:19 skrev Anders Hammar and...@hammar.net:
Child modules can add configuration to mojo
That's where the theoretical before attribute would be useful, right?
Cheers,
Paul
On Thu, Jun 12, 2014 at 3:49 PM, Anders Hammar and...@hammar.net wrote:
Sorry, my bad. I meant the binding in the child to be BEFORE the one on the
parent. I can't alter the declaration in the parent in my
I don't think this is a general use case.
With the same parent, I believe this is a common example:
plugin
groupIdcom/groupId
artifactIdacme/artifactId
version2.3/version
executions
execution !-- before, because of plugin order --
idpre/id
yes, I agree before/after will likely be more convenient in some cases.
--
Regards,
Igor
On 2014-06-12, 17:04, Robert Scholte wrote:
I don't think this is a general use case.
With the same parent, I believe this is a common example:
plugin
groupIdcom/groupId
Hi Igor,
Igor Fedorenko 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
Misconfigured execution order should be reported as build failer.
I don't see how profiles make this problem more complicated. It maybe
little tedious to configure, but I believe it is always possible to add
dependsOn attribute to execution defined elsewhere. So in your example,
the release
The dependsOn would only help if this execution should be done *after*
another execution. However, I think we also need a solution for the
*before* one, unless we say: just manage this by ordering your plugins.
Keep in mind: what to do if executions are defined in the parent and you
want to
FWIW, in my use of Spring Security, I am able to place a security check
within a security filter chain using a before or after attribute. It
makes relative positioning very easy.
Cheers,
Paul
On Wed, Jun 11, 2014 at 2:44 PM, Robert Scholte rfscho...@apache.org
wrote:
The dependsOn would only
It is possible to amend inherited execution configuration, maven will
use plugin GA and execution id to merge the configuration, and I assume
it will or at least can merge dependsOn attribute.
Having said that, I think having both before and after attributes
will make configuration easier in
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
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
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.
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
I actually think the attributes are perfectly fine and won't interfere with
anything. The attributes were always intended to be metadata about the elements
and I think the use of instructing the core about how to order the executions
falls into that category of use.
On Jun 5, 2014, at 9:52 AM,
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
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
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
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
I haven't looked at the patch, but I know at least one case when it'd be
nice to have explicit control over execution order within a build phase.
Lets say you have two plugins, plugin-a with two goals a1 and a2, and
plugin-b with goal b1. It is currently not possible to express the
following
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
Yes, I do think plugins should have some sort of ordinal value associated
to them. However, I am not sure if I like the proposed patch because it
infers the order out of the plugin's id attribute (ex: step1, step2).
Certainly such a feature could work, but it hits that wall in Maven
development
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.
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,
Maven 1.x was before my time :-) Can somebody recap the reasons ordering
executions within a phase was decided harmful?
--
Regards,
Igor
On 2014-06-04, 10:22, Paul Benedict 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
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
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
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
31 matches
Mail list logo
