Thanks for this! Jesse McConnell wrote: > 1) so I did it once with just a normal junit test class and put the setters > on the mojo. Very little new code had to be added to get it working and it > was trivial to take that plugin up to about 85% coverage...the remainder > being some workaround for a windows jdk shortcoming.
I almost get 100% on Windows :) Just needs a test that if you try and delete something that's not allowed to be, it throws an exception. And test John's changes that came after this :) > 2) then I redid it using the approach that Trygvis was doing in his > deb-maven-plugin where you make the mojo a basic adapter to the > implementation which is put together in a standard plexus layout....this > forced the generation of a fair bit more code and a couple of additional > classes, but it certainly felt more true to the nature of what a mojo > is...at least my perception of what a mojo is :) http://cvs.codehaus.org/changelog/mojo?cs=1478&@csTruncateDiffs=false# I recently did the separated content and found it extremely tedious to implement, so I moved back to not doing that - but it depends on the situation as we generally do what you are suggesitng anyway. The original idea was for a mojo was that it could be reused anywhere (automatically generating an ant task wrapper, for example). I think we've steered away from that practically though idealogically would still like them to be the reusable components. We steered away mostly because: 1) the plugin api dependency and extending AbstractMojo 2) the amount of extra work it is to populate the mojo variables, especially when it comes to wiring up the plexus components which is so wasy as is. I think its good to abstract things out like you've done to a degree, but I think the right level for clean is pretty much where it is: deleteDirectory. Some of this needs to move to plexus utils, and the clean plugin should really be delete target, delete output, delete test output. WDYT? So far the approach to factoring has actually taken components out of the plugins themselves - plexus-compiler, plexus-archiver, plexus-utils, etc. I'm actually happy to continue that way for now to clearly separate the responsibilities and build libraries that are reusable outside of Maven entirely. A lot of these are being pushed to Jakarta commons since they originated from code in Ant that is also being developed there. Others go in Maven and its sandbox (the issue tracking stuff, the SCM library, the JXR library, ...) As far as "plexifying" goes, that's probably not the right word, as Plexus isn't being used to instantiate the CleanPlugin object. This is where the testing toolkit might come in - it would do the plexus component instantiation of the plugin, so rather than requiring: plugin = new Plugin(); plugin.setComplexObject( constructComplexObject() ); You'd have: plugin = (Plugin) lookup( Mojo.ROLE, "goal-name" ); with everything wired up, just like it is done in the plugin manager. And then you use the setters to add the customised stuff. This will probably be more obvious when it comes to the site plugin. I think the unit tests are a great start though, and we can probably tackle some other plugins and see how the other issues go (something that has fields with more expressions or @component references). I'll apply the first patch. Cheers, Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
