Consider the following parent pom.xml snippet
<plugin>
<groupId>foo</groupId>
<artifactId>bar</artifactId>
<version>1</version>
<executions>
<execution>
<id>munchy</id>
<phase>...</phase>
<goals><goal>...</goal></goals>
</execution>
</executions>
<plugin>
then in the child I believe you can do
<plugin>
<groupId>foo</groupId>
<artifactId>bar</artifactId>
<version>1</version>
<executions>
<execution dependsOn="some-other-plugin-execution">
<id>munchy</id>
<!-- the rest of configuration is inherited from parent -->
</execution>
</executions>
<plugin>
--
Regards,
Igor
On 2014-06-12, 16:19, Anders Hammar wrote:
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 parent. Then only having "dependsOn"
wouldn't work in a case where we can't update the parent.
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.
Not in the case I describe (I think).
--
Regards,
Igor
On 2014-06-12, 2:23, Anders Hammar wrote:
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, which you want to add a binding before. Then it is not possible
to add the "dependsOn". One scenario would be a parent pom you're
inheriting from.
/Anders
--
Regards,
Igor
On 2014-06-11, 15:44, Robert Scholte wrote:
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 execute your plugin before and/or after these inherited
executions?
Thanks,
Robert
Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko
<i...@ifedorenko.com>:
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 profile will need to define execution with id of the "final
step" and add dependsOf="id-of-sign-step".
--
Regards,
Igor
On 2014-06-11, 15:17, Jörg Schaible wrote:
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 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.
please have a look at the latest comments on MNG-3522, because adding
executions in a profile causes some edge cases, which should be
defined in
advance.
Regards,
Jörg
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
