Right. My point is that regardless of what the original intention may have been, the current process facilitates laziness via SNAPSHOTs. Without them, incremental builds would be necessary, which would give fixed version numbers with known binaries.
If the plan is to take actions to help prevent users from having things break on them, this may be easier than the path you outlined. -- Kevin > -----Original Message----- > From: Brian E. Fox [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 12, 2007 12:59 PM > To: Maven Developers List > Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
