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:
com
acme
2.3
I don't think this is a general use case.
With the same parent, I believe this is a common example:
com
acme
2.3
pre
...
...
post
...
...
That's where the theoretical "before" attribute would be useful, right?
Cheers,
Paul
On Thu, Jun 12, 2014 at 3:49 PM, Anders Hammar 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 scenario as I'm
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" :
>
> Child modules can add configuration to mojo executions con
Consider the following parent pom.xml snippet
foo
bar
1
munchy
...
...
then in the child I believe you can do
foo
bar
1
munchy
--
Regards,
Igor
O
> 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 pa
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,
>
> 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
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 i
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
wrote:
> The "dependsOn" would only help if this
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
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 profi
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 orderi
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 wrote:
> Agreed. Explicit order values are not good.
>
> It should be like the reactor in which the order is
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.
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 som
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 d
Good question. I haven't thought of that. In all the examples presented
thus far, the developer had control over all the 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,
Mojo executions bound to in packaging type lifecycle mapping have fixed
"default-" 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 ex
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,
After giving it some more thought, I think interpolating the 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
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
Thanks for your reply Jason.
So it seems there are some possibilities for this ticket: either
interpreting the 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 "h
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 with
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 ru
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
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
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 attribute (ex: step1, step2).
Certainly such a feature could work, but it hits that wall in Maven
development lan
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
Sin
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 exec
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 sti
31 matches
Mail list logo
