This pretty much describes our world too. And I couldnt agree more with the sentiments that code in *all its guises* must be explcitly managed. you don't compile arbitrary code, don't use arbitrary compilers, don't link against arbitrary libraries... arbitrary bad. Build scripts are code, christ even my shell is a dependency to be managed (mid-90s multi-platform C++ coming back to haunt me). As others have said I think migration and upgrade scenarios are better supported by tools, plugins and docs, not inference and discovery (and by this i mean a plugin that tells you what is potentially available for upgrade)
J Brian E. Fox wrote: > > Here's how I see it in 2.1: > > Command Line Invocation: > -No change. That is if a version is specified in the POM or Plugin > Management, use that. Else, use RELEASE. If a fully qualified plugin > name is used in place of the prefix, use that (ie > org.apache.maven.plugins.maven-dependency-plugin:2.0-alpha-4). > > Pom binding: > -Same as dependencies. That is you may omit a version in your pom, > provided it is set in pluginManagement. If not, the build fails. I'm on > the fence if RELEASE should be allowed in place of a pinned version (but > still must me listed in the POM, can't be assumed). I'm leaning towards > no. > > > In my corp builds, this is effectively what I do now. Anything used > anywhere in my poms is placed into pluginManagement. Any other plugin I > may use sporadically on the CLI, I just get what's out there. I don't > have any formal part of my build that requires any CLI invocation > anyway, it's all bound to the poms so a "mvn install" or "mvn deploy" > produces everything official. (including assemblies that use > assembly:attach on pom projects made for that purpose) This means that > anything not already set in pluginMgt is just for info like help:xxx > etc. > > I don't see large plugin packages as being particularly usefull for this > problem. Just not assuming RELEASE in a pom binding should solve it. > Trying to coordinate plugin packages together will be a large effort and > people will probably just start listing individual numbers anyway as > soon as a plugin gets release. Not to mention the extra indirection > trying to figure out if package 2.0.6 contains Assembly 2.1 or > 2.2-alpha-1. > > -----Original Message----- > From: John Casey [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 11, 2007 12:55 PM > To: Maven Developers List > Subject: Remove auto-resolution of plugin versions from Maven 2.1 > > Hi everyone, > > I'd like to make sure we're all on the same page with the plugin > auto-version resolution stuff that we've been discussing lately (on the > assembly-plugin vote thread, for one thing). I think it's clear that we > cannot continue to allow Maven to resolve RELEASE or LATEST > meta-versions for plugins any more. I'd actually argue that this is bad > practice for ANY artifact that is to be resolved, including site skins, > etc. since it kills our ability to deprecate features. > > I'd like to completely remove this from the DefaultPluginManager in > trunk, so we can start moving away from this practice immediately. > > I guess this is an informal vote on the subject, but I wanted to get > everyone's opinions before I move on it, since it's a fairly important > change. > > Here's my +1. > > -john > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Remove-auto-resolution-of-plugin-versions-from-Maven-2.1-tf3560617s177.html#a9970386 Sent from the Maven Developers mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
