I always lock down all plugin versions in my production at release time and use snapshots, if needed, during development time. The draw back is that the release date is heavily depent on all snapshot plugins to be released first. Lucky, i have internal repo to deploy a known snapshot. For your case it will be tough, since you dont have an internal repo to fall back.
-D On 1/22/07, Barrie Treloar <[EMAIL PROTECTED]> wrote:
On 1/23/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? Yes, this is what lead me to write http://docs.codehaus.org/display/MAVENUSER/Patching+Maven+Plugins So that I could enjoy the benefits of a snapshot plugin but without bringing in every other plugin at the same time. If you are not in a corporate environment where you can setup an internal repository you may have more issues to resolve. e.g. there is a defect (I don't know if it is in JIRA yet) where if different versions of the artifact reside in different repositories then the artifact incorrectly resolves to central. This has the effect that maven thinks your newly internally released plugin is available on central, when of course it is not. Wrapping with mvn-proxy hides this problem by aggregating all the repositories. > #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. I would have thought that * no version * LATEST * RELEASE all resolve to the same version on a non-snapshot repository. I'm happily using "1) Have no version" in conjunction with internally releasing snapshot plugins that I require. The benefit is also that when an official release occurs my internally released snapshot is no longer used. The downside is that I must check to make sure all the defects I had patched in my internally released plugin are applied to the official release. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
