On Wed, 2003-10-22 at 02:45, Brett Porter wrote: > > 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?
It's need to test jelly plugins, but it just runs as another maven goal. No reason it can't move out and be run somewhere else. If separated from the core it could actually be tested against more than one version of maven. So if we make changes to the touchstone to test new functionality you could actually check out as many versions of maven as we wanted to and run the touchstone plugins against them. Which would probably make them more useful. Testing plugins against the bootstrap is probably the least useful form of testing. It just happens to be the only one we have at the moment. But testing plugins, whether the touchstone or otherwise, should be able to be performed against any version of maven. > 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. I think you can get away with form I noted but I will give a fleshed out version tomorrow. But you get that refactored code in here and we'll whack it out! > > 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. Yah, plugin specific stuff in the actual touchstone build could be removed and repackaged in a small project with the touchstone plugins. > Cheers, > Brett -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
