Yeah, I will follow up this thread with wiki documentation. I'd like to approach it as more of a "testing maven components" with a special section on plugins, personally...because I think a lot of the principles will apply in both cases. WDYT?
Kenney: yeah, I actually revamped/gutted the it plugin for this one...it's dependent on the maven-invoker API that I developed in the open for a client. This API has a good set of tests, and is intentionally close to the embedder API so they can eventually be merged with an optional 'fork' flag. I wanted to use this plugin name rather than revamping the IT plugin, just in case there were plans for other things in the existing plugin...and also to escape the concept that this plugin is only for integration testing... ;-) I'd like to look at what features the IT plugin provides that this one doesn't, and maybe converging them where the behavior can be generalized as non-IT-specific. -j On 8/10/06, Brett Porter <[EMAIL PROTECTED]> wrote:
cool. Can we get this written up in the wiki/docs like Jesse's stuff was? How about starting the "plugin developers centre" on the website? :) - Brett On 11/08/2006 8:06 AM, John Casey wrote: > Hi, > > I wanted to let people know about something I've been working on for the > assembly plugin. As anyone watching the commit notifications has probably > noticed, I've recently completed a large refactor of the assembly plugin, > with the aim of making it more modular and easier to unit test. While this > has made the source easier to comprehend and unit test, I've learned an > important lesson in the process: test coverage numbers don't tell the whole > story. Some of you have tried to tell me this in the past, but let's just > say there's nothing like experiencing something firsthand... > > So, to make up for deficiencies in the unit tests (not checking every > permutation of nulls, for example), I wanted to put together some > functional > tests which would help us set a high water mark for future releases, to > prevent regressions (or try to). The trouble has been that this really > requires running the plugin within its platform - i.e. Maven itself - and > checking the results of various builds. Further complicating things is the > fact that plugins are sometimes resolved early in the build lifecycle, > meaning the instance that actually gets tested will be something resolved > from the local repository instead of the one you just built. > > This brings me to my announcement: I've written two new plugins, which are > currently in the sandbox, and which allow developers to run > integration-test > builds for a plugin. The way it works is relatively simple: > > 1. backup the local repository plugin directory structure, and stage out > the > fresh one > 2. clear the resolved-plugin cache of the plugin you just built > 3. run a series of Maven builds, executing pre-build and verification > scripts before/after each build to setup and verify the test, respectively > 4. de-stage the plugin, meaning restore the local repository state prior to > the integration test setup > > For items 1, 2, and 4, I've written the maven-plugin-test-plugin (I know, > ugly name). Item 3 is another plugin I wrote, called the > maven-invoker-plugin, which can be used to run any [set of] builds. It uses > beanshell scripts for prebuild and verification, can take CLI-injected > properties from a test.properties file in the build directory, and supports > a goals.txt file for customizing the build command used per-project. > > As I mentioned, both of these plugins are in the sandbox. I've also > deployed > them to the apache.snapshots repository, and you can find a sample > configuration in a profile in the maven-assembly-plugin POM. > > Hopefully, we can use and evolve this pattern to start enabling > functional/integration tests for plugins which are easy to understand and > maintain. > > Cheers, > > John > -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
