Is there some particular use case for allowing multiple plugins with different versions confusing things?
Maybe if it comes installed with one version and you get a project with a dependency on a newer one?
I think dying a horrible death is a great thing to do if more than one turn up in the extracted plugins directory.
Ahhh... now I see the use case.
So as a project builds, there should only be 1 plugin of a given id loaded, but there may be multiple unpacked (contrary to your statement).
I don't really like the idea that an unpacked plugin would be deleted just so that it isn't used by maven for a particular run.
Perhaps a manifest of default plugins for a release be kept. The plugin installer updates the defaults. A project can override the default - unloading the previous one and loading the specific one it needs. I'm not a big fan of having a list that can be destroyed, but I at least it declaratively states which plugins are to be used in the default run.
We've done a similar thing with reports, you get X reports by default, customise extra ones as required. There may be some crossover between reports / plugins (registration / deregistration concepts).
I contemplated this... it's a fairly simple solution (simple is good imo). I can't see any added advantage in having other levels of visibility - eg protected. Unless of course we wanted to allow plugin inheritance (complexity == bad - this would be very confusing I think. I prefer delegation over inheritance for most things).
As I have mentioned before, we need to get a bit clearer about which goals can have been touched from outside a plugin. I'd prefer that goals were internal unless marked otherwise (obviously we need a deprecated phase for this).
What about internal goal names having no namespace? So <goal name="my-local-goal"> is only internal to that plugin (and can be used from the cmd line only if it were in a maven.xml).
Have a way of overriding it by group ID when needed: maven au.com.f2.build::war:war maven maven::war:war (= maven war:war) If someone enters "war:war" and there are 2 options, we should always use anything that is a maven groupId. If 2 others, die horribly, but say why :)
Not really sure if there is any value in :: over :
Would something that pregoalled war:war run before au.com.f2.build:war:war ?
<preGoal name=":war:war"> - Only runs before the specific nonamespace war:war
<preGoal name="war:war"> - Runs before any war:war
Cheers,
Ben
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
