I have two or three I could abstract down, plus some teeny (project A,
Project B) samples I generated to teach people Maven.
I would actually suggest not one, but three or four, including at
least one that pulls in some common external plugins to see if
interaction breaks (says a plugin creator... lol)
But I'll try to think through the actual scenarios so we can have
enough projects to execute a meaningful suite without too much
duplication. Hmm. Maybe I'll through up a table on the wiki to keep
track of the case coverage.
Christian.
On 13-Feb-08, at 14:28 , Brian E. Fox wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
