Apologies for the delayed response. I must've missed the message. I'd have to check with Andrus Adamchik, since he was the guy that had to keep fixing the POM. I know for certain that we've been bitten numerous times by the Geronimo folk though, both transitively and directly. We also got bit by the whole surefire/classloader issue, which the suggestions in this thread would take care of.
For my own stuff, I've had to rely on SNAPSHOT for Selenium and Cargo, because either the released versions were broken in some way or didn't support newer releases of external software. At least in the case of Selenium, the authors know that they're released version is broken and their response is to just use SNAPSHOT. That's the sort of scenario I'd like to see avoided if possible. -- Kevin > -----Original Message----- > From: John Casey [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 12, 2007 5:24 PM > To: Maven Developers List > Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 > > I'm interested to know which snapshots bit you guys so hard? > Was it a [set of] internal snapshots, or were they snapshots > from Maven or some other OSS project that you depend on or > use? If we start talking seriously about shorter dev cycles > and milestone releases with less of a barrier to release (for > alpha quality, for instance)...and start shunning snapshots > as an acceptable mechanism for distributing pre-release > code...would that have helped you all? > > -john > > On 4/12/07, Kevin Menard <[EMAIL PROTECTED]> wrote: > > > > I agree. I am suggesting that it's a little too easy to > use SNAPSHOTs > > and that all that wonderful time maven was supposed to save you in > > preparing releases is trumped by the time it takes to just append > > -SNAPSHOT to a version number. Sure, it's people abusing > it, but it's > > easy to abuse and looks like it's officially condoned as proper > > behavior. Things get even murkier when transitive dependencies are > > considered. So, I'm not suggesting dumping SNAPSHOT wholesale, but > > making it more difficult to distribute an artifact via > SNAPSHOT (maybe > > require the end user to have to agree to use a new SNAPSHOT > each time > > one is available or something). > > > > Maybe we'll just have to agree to disagree. I will say that this > > matter has bitten the Cayenne team a few times now, and we've come > > close to dumping maven altogether. It got to the point > where we had > > to start pinning SNAPSHOTs by timestamp via a guess and > check method. > > Perhaps the plugin Nigel suggested would help matters, though. > > > > -- > > Kevin > > > > > -----Original Message----- > > > From: Brian E. Fox [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, April 12, 2007 3:10 PM > > > To: Maven Developers List > > > Subject: RE: Remove auto-resolution of plugin versions from Maven > > > 2.1 > > > > > > Snapshots are a very good thing for internal > development. It would > > > be impossible to manage my builds without them. I think > that people > > > using snapshots of plugins are a symptom of another > problem -- long > > > release cycles. Just because people do bad things with snapshots > > > doesn't mean snapshots should go away. > > > > > > It already takes a little effort to get at them, the > snapshot repo > > > isn't part of the super-pom, so if you go out of your way to get > > > them, you should understand the consequences. It's like > me picking > > > up an unstable version of some jar and then complaining that it > > > broke later and asking the creators to stop releasing unstable > > > versions at all(that are clearly marked as such). People > would then > > > just go get the code anyway. > > > > > > -----Original Message----- > > > From: Kevin Menard [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, April 12, 2007 1:09 PM > > > To: Maven Developers List > > > Subject: RE: Remove auto-resolution of plugin versions from Maven > > > 2.1 > > > > > > 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 > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > - 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]
