-1
Handling one offs from the command line is not what we want.
Executions embedded into the lifecycle are meant to be just that a way
to include many things you need in the lifecycle.
If you need something different on a per situation basis it should be
a plugin configuration that you need encapsulated in a profile.
This would just create another confusing way to achieve something on
the command line and and supporting this in IDEs would also be
loathsome.
On 10-Nov-08, at 2:43 PM, Paul Gier wrote:
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]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.
-- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
