On 1/22/07, mraible <[EMAIL PROTECTED]> wrote:
What's the best way to specify versions for Maven Plugins. In the AppFuse
project, we're distributing archetypes that have plugins pre-defined in
the
pom.xml files.
Should we:
1. Have no version
2. Use the latest version in the Maven repo
3. Use <version>LATEST</version>
4. Use <version>RELEASE</version>
We've been using #1 and the downside seems to be that snapshot
repositories
are checked for updates. Does this problem go away when we don't depend on
any snapshots?
#2 seems good, but it requires our users to manually update the version
number when a new release comes out.
I'm looking for the method that doesn't cause a slowdown (i.e. checking
repos for updates) in the build process, but auto-upgrades when new
releases
come out. We have found issues with some plugins (i.e. Jetty 6.0.1doesn't
work with JSF), so for those we're willing to hard-code the plugin
version.
This is not just an issue for plugin versions ... exactly the same issues
apply to dependency versions. I've been thinking about a strategy of being
explicit on all versions, but using the range syntax ... with a range
covering all the combinations I have actually tested with :-).
IMHO, there is a significant potential problem when you use any of the other
options ... you are implicitly trusting the supplier of your plugin (or
dependency) to not screw you by breaking backwards compatibility in some
*future* version. I'd rather be conservative in what I claim in a POM, but
more liberal in what I describe (in text) in release notes or things like
that.
A negative side effect of this strategy is the potential need to update the
range later on, when a new version of something you depend on has been
released, and it *does* actually work. But that is the sort of thing I'd
rather document ("hey, even though the POM claims that this works with
Spring 1.2.8, you can actually use Spring 2.0 successfully"), and let people
override explicitly in their own POMs until my next release comes out.
Thanks,
Matt
Craig
