Snapshots are not intended to be depended on outside the context of the team working on it. Nothing released can ever had snapshot dependencies (on plugins or dependencies). I think what you are seeing is a symptom of longer release cycles. People need something fixed, they take a snapshot and move on. Unfortunately this is dangerous as you noted. We are working on getting tighter release cycles and I think it's starting to show recently.
Here's how I deal with instances where I need a snapshot plugin in my corp build: 1. Checkout the code for the snapshot. 2. Build it, changing the version to something like 2.0-[companyname]-svnrev 3. If I have to patch the source at all, I take the whole thing and put it in my svn. If not, then the svnrev in the release points me back to where I got it in case I need it later. 4. Deploy it to my repos. 5. Use this now "internally released" version in my builds. It's a little extra work, especially when you get stuff that has further snapshot dependencies etc, but it is most definitely stable and reproducible. (even if our repo disappears). -----Original Message----- From: Kevin Menard [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 12:50 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 A bit of a departure from the discussion, but still related . . . It may be worthwhile to rethink the whole SNAPSHOT system, too, then. Way too many plugins and dependencies sit in a SNAPSHOT limbo, presumably because it's simpler than cutting a release. And then SNAPSHOT to SNAPSHOT may break builds. In this case, the user has specified precisely the version he needs for his build (perhaps only SNAPSHOT has a particular bug fix), but he's still just as vulnerable to having the rug pulled out beneath him. -- Kevin > -----Original Message----- > From: Brian E. Fox [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 12, 2007 11:08 AM > To: Maven Developers List > Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 > > John, I think you've hit the nail on the head here. If you look at it > this way, your plugins used are no different than dependencies. It's > very dangerous to depend on the latest version of some jar from the > repo, and likewise plugins. We don't default to grabbing the LATEST > dependency, the same should be true for plugins. > > -----Original Message----- > From: John Casey [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 12, 2007 11:00 AM > To: Maven Developers List > Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 > > One thing I wanted to add: > > To me, it's critical to view your build script (or POM, or whatever > binding you have to a build infrastructure) as a piece of the project > code. The build - definition, shall we say? - is responsible for > modifying your source code into a binary that works the way you would > expect, and there are many options for the different steps involved in > this process. This complexity means that there is a risk that the > build process could introduce unexpected problems that may range from > a file being out of place in the resulting binary, to a compiler > option turned off that should be on, to using the wrong compiler. > > In other words, your build process is subject to bugs just like your > project source code is, and needs to be tested alongside everything > else. If you wait until release time to exercise a particular piece of > this code, that's not so different from having a piece of code with > absolutely no tests make it into your final binary. This is the > biggest reason why I feel that locking down the POM at release time is > dangerous. > > -john > > > --------------------------------------------------------------------- > 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]
