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 <[email protected]> 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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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
<[email protected]>:
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: [email protected]
For additional commands, e-mail: [email protected]
------------------------------------------------------------
---------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
