6 messages in org.apache.maven.usersRe: What's the best way to specify ve...| From | Sent On | Attachments |
|---|---|---|
| mraible | Jan 22, 2007 7:17 pm | |
| Barrie Treloar | Jan 22, 2007 7:50 pm | |
| Dan Tran | Jan 22, 2007 8:01 pm | |
| Carlos Sanchez | Jan 22, 2007 8:46 pm | |
| Barrie Treloar | Jan 22, 2007 8:47 pm | |
| Craig McClanahan | Jan 22, 2007 9:53 pm |
| Subject: | Re: What's the best way to specify versions for Maven Plugins? | |
|---|---|---|
| From: | Craig McClanahan (crai...@apache.org) | |
| Date: | Jan 22, 2007 9:53:38 pm | |
| List: | org.apache.maven.users | |
On 1/22/07, mraible <ma...@raibledesigns.com> 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