> 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).
Yep. Sorry, I was thinking that using dependencies didn't unpack it, but it does. What should really happen is every plugin you ever install should be unpacked and cached in your local plugins directory. However, this should not impact the rules for what actually gets loaded too much. Those were described in the other email which dIon agreed with. > 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. No, me neither :) > 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). This is a good idea. In fact, there is a large crossover in that the reports are all in a plugin. But they may not always be the case I guess, plus you can have >1 report per plugin. On the other hand, plugins need to know versions where reports don't - although there is no harm in limiting to a certain version there either. For instance, a while back the checkstyle report stopped working until people upgraded their config files to a new format after the plugin upgraded to CS-3. > 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 I don't think you can preGoal into an unknown plugin without knowing what is doing. For instance, com.microsoft:war:war could actually be a Maven plugin for world domination, not building web applications. I take back what I said about giving Maven special treatment. That could get confusing. But then you can't ever preGoal on war:war because you don't know which is which. You'd always have to give the groupId :( - Brett
