On Sat, Oct 16, 2010 at 6:20 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > On 10/16/10 12:52 PM, James Carman wrote: >> >> On Sat, Oct 16, 2010 at 12:23 PM, Niall Pemberton >> <niall.pember...@gmail.com> wrote: >>> >>> Consistency is good, but deciding something based purely on >>> *consistency* rather than the merits of the situation is mindless. >>> >> >> Trying to keep things consistent is being mindful of the user's needs. >> The consistency is part of the situation. When you go to pool >> version 3, you'll have: >> >> 1.x - commons-pool:common-pool with package org.apache.commons.pool >> 2.x - org.apache.commons:commons-pool with package >> org.apache.commons.pool2 >> 3.x - org.apache.commons:commons-pool3 with package >> org.apache.commons-pool3 > > From what Dennis says above, it is not obvious to me that the artifactId > change for v 3 will be necessary - i.e., just bumping the version number > will allow multiples to be on the classpath at the same time. Can someone > answer this question definitively? If it will be necessary to move to pool3 > later, then I agree with James that we may as well do it now.
What James says wrt to pool3 is correct. Maven *resolves* dependencies to pick a single version of a groupId/artifactId based on the dependency tree. If not people would have continued problems with multiple versions of the same artefact in their classpath. >> Makes lots of sense to the users. >> >> Again, it comes down to "you don't work on this project so stay out of >> its damn business" and "the release manager is doing the work so they >> can do whatever the hell they want." So, why don't we just do what >> Incubator does and have a mini-PMC for each subproject since you don't >> want other members of the Commons PMC butting their noses into a >> project they don't actively participate in? > > I don't think that is what Niall meant and its certainly not how I see > things. A great strength of our community is that we *welcome* input for > one another as we make decisions at the component level. We all benefit from > that. The tricky bit is to agree on what we standardize across components. > We have a long tradition of letting component communities and those who > step up to RM releases make a lot of decisions independently. That does not > mean that we shouldn't listen to feedback from the community or provide it > when we have something to say. Nor does it mean that we are not *all* > responsible for *all* of our components. Sometimes we disagree and > sometimes it takes a while to get to consensus, but IMO we are *much* better > off managing Commons as one community. +1 >> At this point, I really don't care what you guys do. In the grand >> scheme of things, it has absolutely zero impact on me what you do with >> this code. I'm tired of arguing about this stuff all the time. > > I am sorry you feel like that atm. me too. Niall > Phil --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
