Absolutely. We simply need a good example of a project that uses various common tools: jars, wars, ears, assemblies, moving resources with dependency, scanning with checkstyle/pmd/cobertura. It should have a simulated corp pom etc. The trouble with most touchstone builds are they are enterprise examples that are closed source and not easy to replicate without time. The touchstone doesn't need tons of source, it's mostly about the structure.
-----Original Message----- From: Christian Edward Gruber [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 13, 2008 11:09 AM To: Maven Developers List Subject: Re: Maven and preset plugin versions How can I help? Seriously. I'd be willing to put some time into it. Christian. On 13-Feb-08, at 13:47 , Brian E. Fox wrote: > Yes we do have plans for a touchstone build to test against. Getting > one > made is actually the problem ;-) > > -----Original Message----- > From: Christian Edward Gruber [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 13, 2008 10:26 AM > To: Maven Developers List > Subject: Re: Maven and preset plugin versions > > This is true, but it might be appropriate for the maven core group to > provide a criterion (or criteria) for inclusion of the new version. > Some sort of sufficiency of testing, full regression in an isolated > integration environment, etc. If the core group can set a baseline of > quality that has some criteria that can be objectively verified, then > the plugin authors would have a level to shoot for. > > Certainly, I think that would mean developing a set of canonical > projects that would have to be built with the new plugins. Not just > in /src/it of the plugin itself, but larger test that would have to be > tested against the integrated whole. If the test projects had to be > altered to support the new plugin functionality, then that becomes > either 1) a regression failure, or 2) non-destructive new features. > Either way, the delta forms a great part of a release not on how to > update your projects to support the new version. > > The trick, of course, if finding a "sufficient" project suite to > exercise the whole and build it out. Maintaining it should be less > heavy, since it IS the canonical project. > > Christian > > On 13-Feb-08, at 01:06 , Brian E. Fox wrote: > >> It's really up to the plugin author to document compatibilities >> rather >> than Maven core running around and building a list. >> >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] >> On Behalf Of Paul Benedict >> Sent: Tuesday, February 12, 2008 5:09 PM >> To: Maven Developers List >> Subject: Re: Maven and preset plugin versions >> >> Brett, >> >> I didn't know that. I never knew that kind of feature existed. Can >> the >> minimum recommended version be listed in Maven release notes though? >> It >> would be nice to a have a table with what versions should be used >> with >> 2.0.8for the best support. Education and visibility on this issue is >> key, imo. >> >> Paul >> >> On Feb 12, 2008 5:51 PM, Brett Porter <[EMAIL PROTECTED]> wrote: >> >>> But this is how it already works, if I'm reading correctly. The >>> minimum version of Maven for a plugin is specified by the plugin >>> itself in the prerequisites tag - if you use an older version of >>> Maven, you will get the last version of the plugin that worked with >> it. >>> >>> - Brett >>> >>> On 13/02/2008, at 8:22 AM, Paul Benedict wrote: >>> >>>> I've been watching the discussions about introducing a fix set of >>>> plugin >>>> versions per Maven version. I see benefit and drawback to each side >>>> of the >>>> argument. >>>> >>>> Here is another proposal which is dear to my pain :-) >>>> >>>> Provide the minimal compatible version of each plugin (of group >>>> org.apache.maven.plugins) in the super pom. For instance, when I >>>> upgraded to >>>> Maven 2.0.8, it would have been nice (stupendous!) to automatically >> be >>>> bumped to surefire 2.4 because the two truly needed each other in >>>> integration testing. I imagine there are other cases when plugins >> have >>>> dependencies on other parts of the Maven core, but I could be >>>> wrong. >>>> The >>>> desire is for children pom to provide the "better" versions if >>>> necessary, >>>> but Maven should at least provide the minimum versions. >>>> >>>> Paul >>> >>> -- >>> Brett Porter >>> [EMAIL PROTECTED] >>> http://blogs.exist.com/bporter/ >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
