> 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. > 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). > Having a guideline for naming goals would also be > worthwhile, as more plugins are created, we will have > collisions. 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 :) I use :: just to distinguish those few valid no-namespace goals, which should be the default goal of the namespace (maven test, site, console etc). > What > is the goal resolution hierarchy? is there one? It's a flat hierachy because of the way the cache manager works I think. But I think the above is feasibly, and ends up no worse than java itself (ie there can still be groupId clashes, but serves you right for using a domain name you don't own, or using something generic :) > I realise I have asked more than I've commented on! :) - Brett
