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]
