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> ? -- Christian --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
