> These below should go as well. The coupling on the license > plugin needs to be removed, multiproject certainly isn't > core, and neither is plugin. > > > - license > > - multiproject > > - touchstone > > - touchstone-partner > > - plugin
Isn't touchstone needed to test the maven code though? The touchstone plugins don't test other plugins at all, just behaviour of the plugin manager from what I can tell. > The touchstone could probably even go. I'm going to out a > proposal where the names of goals are done in such a way that > we follow the once established convention of > <plugin>:<action> (e.g. jar:build). With this the goal is > linked to it's plugin explicity. It would be easy to detect > whether the plugin for that goal is present so it could be > downloaded and this method would scale to any number of > plugins. I'll whip it off tomorrow it's only a few paragraphs. Yep - I've thought of doing the same. As discussed on the list a while back though, you'd need to be able to say: maven:jar:build (plugin-groupId:plugin-artifactId:goal) to fix namespace issues. > Then this list above will be moot as it won't matter where > the plugins are. Also a testing method that is not bound to > the bootstrap is necessary so that we and others can test > plugins correctly against any number of desired versions not > just CVS HEAD. This testing method is already in place for some plugins (the plugin-test project). More needed, and whatever is plugin specific in the touchstone needs to be moved. I mentioned this earlier. Cheers, Brett
