Mark, maybe this is not so obvious, but Maven internally has ClassLoader isolation between plugins. This is comparable to a servlet container where 1 webapp only can see its own classes. This way it is no problem that there are more versions of a plugin (or any other dependency) being used in the same maven build.
LieGrue, strub --- On Mon, 6/20/11, Mark Derricutt <m...@talios.com> wrote: > From: Mark Derricutt <m...@talios.com> > Subject: Re: [VOTE]: release maven-changes-plugin 2.6 > To: "Maven Developers List" <dev@maven.apache.org> > Date: Monday, June 20, 2011, 8:27 PM > Wow - that seems like a hell of a lot > of releases having to be made... > > This post is probably drifting off topic but the thing that > strikes me here > is that this is the exact reason why maven supports version > ranges - so that > you don't have to make a plethora of rolling releases just > because one > change was made downstream. > > It's no wonder a lot of version range bugs in maven never > get fixed if none > of the plugins or maven itself actually uses them. Of > course this only > solves the problem where an upstream release contains > non-breaking changes > for its downstream users which hopefully, for bug fixes > would be more often > than not. > > Locking down versions is good for third party dependencies, > but I'm very > much of the mind that ranges should be used for sibings, > would certainly > solve the problem of transitive release blowouts. > > > -- > "Great artists are extremely selfish and arrogant things" > — Steven Wilson, > Porcupine Tree > > > On Mon, Jun 20, 2011 at 6:13 PM, Kristian Rosenvold < > kristian.rosenv...@gmail.com> > wrote: > > > > > > > Den 19.06.2011 23:08, skrev Gavin McDonald: > > > > > >> I would be happy with weeks to be honest. Then > again I have been used to > >> being around > >> slower projects that have released only every 2 or > 3 years once 1 or 2 > >> hundred issues have > >> been gathered into a release. And the release > process itself takes weeks > >> of work to > >> achieve. > >> > >> Therefore ignore me, 3 issues seems like doing a > days work, then release, > >> then another days > >> work, then release etc ... > >> > >> > > Given a very quick count, the apache maven project > contains something like > > 90 individually deployable and separately votable > artifacts. Our users > > upgrade these components individually according to > need. Each component is > > individually tested and voted for; maven is not a > monolithic application and > > should not be released as one. > > > > The downside of this componentization is that > sometimes fixing a single > > issue leads to the redeployment of multiple artifacts, > at the moment I'm > > working on 1 issue that will require the > > redeployment of 8 different artifacts (6 votes at > apache, 2 elsewhere) > > before it's closed in its full extent. Most likely > I'll have votes for 2 of > > these "soon" and I'll just let the remaining 4 roll > out > > together with releases planned by others. But in this > context I simply > > refuse to consider if a single release vote is too > large or too small. > > > > From an agile perspective there's potential to getting > a lot more issues > > fixed with a single year than the kind of project you > mention. I have no > > specific stats but I assume we fix at least a thousand > issues every year. > > > > Some of our projects have sufficiently good automated > test coverage that I > > suspect we could allow incremental .1 releases to go > without a vote > > entirely. I'm not sure if this is something we're even > allowed to consider > > ;) (Surefire would probably qualify, assuming we did > some kind of formalized > > "continious production" kind of review) > > > > I think ideally we should release every top-level > component every 6 weeks > > or so. But that means we'd have 1-3 votes every day > ;) > > > > > > Kristian > > > > > > > > > > > > > ------------------------------**------------------------------**--------- > > To unsubscribe, e-mail: > > dev-unsubscribe@maven.apache.**org<dev-unsubscr...@maven.apache.org> > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
