Christian Schulte wrote:
Stephen Connolly wrote:
AFAIK,
The execution id refers only to a specific plugin, and each execution can
only match a specific phase... so I don't see the need to tie the execution
to a goal name, neither to the plugin name...
What I see as bind important is if the plugin is bound to multiple phases
and you want to configure the different phases differently...
At that point I think you're left with "breaking" the id as an id.... and
you'd end up using a wild-card type matching, e.g.
<id>lifecycle:jar:*</id>
or
<id>lifecycle:*:compile</id>
or
<id>lifecycle:*:*</id>
All of which are useful, and do not require a schema change, and are rather
unlikely to interfere with existing builds... but it feels ugly to me... and
yet I'm proposing it! ;-)
There must not necessarily be a lifecycle in use at all. How would this
execution id match standalone executions ? E.g.
mvn eclipse:eclipse
mvn netbeans-freeform:generate-netbeans-project
Consider a plugin with multiple such standalone goals for which a user
needs to provide configurations per goal. Neither the lifecycle nor the
packaging plays any role here, I think. E.g.
mvn ide:eclipse
mvn ide:netbeans-freeform
<id>none:*:none</id> ?
What about adding new syntax to the goal string? So that from the command line
you could write something like this to refer to specific execution configs:
mvn eclipse:eclipse{execution-1}
or
mvn eclipse:eclipse{execution-2}
The curly braces already seem to be associated with execution ids in maven's
logging output. This would mean that components.xml file in maven core could be
changed to provide execution IDs for each plugin that is executed, but probably
no one wants to manually update this all the time.
IMO the wildcard syntax is more than what is needed, and will make the pom a
little less readable. The choice should be configure all executions or just
one, otherwise it starts getting too complicated.
After looking into the current behavior a little more, it is possible to execute
the same plugin goal twice in the same phase. So I think all the naming schemes
proposed except maybe Brett's (groupId:artifactId:sequenceNumber) could run into
conflicts in the future. But if we include a sequence number, then what happens
if you add another execution of an existing plugin to the lifecycle? Do all the
sequence numbers have to increment to make room?
I think if we add the goal name to the execution like Benjamin suggested, we
will be unlikely to run into conflicts. So I would prefer something like:
default-lifecycle-compile
default-lifecycle-testCompile
When building, this logs to the command line like this:
[INFO] [compiler:compile {execution: default-lifecycle-compile}]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
