On 16 October 2010 15:25, James Carman <ja...@carmanconsulting.com> wrote: > Well at the time, we were under the impression that maven oils only allow > one copy of the group:artifact on the classpath. Has that changed?
No, but if one changes groupId, then there is no need to change artifactId as well. > On Oct 16, 2010 10:21 AM, "Phil Steitz" <phil.ste...@gmail.com> wrote: >> On 10/16/10 10:03 AM, James Carman wrote: >>> We have come up with a game plan that allows multiple versions of our >>> libraries to be on the classpath at the same time (changing artifact and >>> package name). Lang is doing things according to that plan and we hope >>> others will follow suit. We had this discussion long ago and we don't > need >>> to rehash it now. >> >> I don't understand exactly what changing the artifactId accomplishes >> beyond what changing the package name does. Can someone explain? >> IIUC what Dennis is saying, just bumping the version will allow >> multiple versions to be on the classpath at the same time and >> changing the package name will avoid conflicts. What more are we >> looking to accomplish by changing the artifactId? >> >> Phil >>> On Oct 16, 2010 9:56 AM, "Dennis Lundberg"<denn...@apache.org> wrote: >>>> When you say consistent, what are you referring to? The fact that lang >>>> has done it once? >>>> >>>> It is not the Maven way to change the artifactId when a new major >>>> version comes out. And since we are talking about the Maven >>>> "coordinates" (groupId, artifactId, version) I think it is best to >>>> follow the standard Maven way of doing it. >>>> >>>> On 2010-10-16 00:28, James Carman wrote: >>>>> I didn't say it was required. I said it was a good idea, because it >>>>> would keep things consistent. >>>>> >>>>> On Fri, Oct 15, 2010 at 5:39 PM, Dennis Lundberg<denn...@apache.org> >>> wrote: >>>>>> Changing the artifactId is not necessary. At least if we predict that > we >>>>>> will not change the groupId again. In Maven the combination of > groupId, >>>>>> artifactId and version is unique. So > org.apache.commons:commons-pool:2.0 >>>>>> and org.apache.commons:commons-pool:3.0 are two unique artifacts. >>>>>> >>>>>> On 2010-10-15 20:43, James Carman wrote: >>>>>>> If we do change the package name to pool2, then I'd suggest the >>>>>>> artifact id change too so that everything stays consistent. So, the >>>>>>> new artifact id would be commons-pool2 rather than commons-pool. >>>>>>> >>>>>>> On Fri, Oct 15, 2010 at 2:40 PM, James Carman >>>>>>> <ja...@carmanconsulting.com> wrote: >>>>>>>> If you change the group id, it's probably best to go ahead and > change >>>>>>>> the package names also, in case two versions show up on the same >>>>>>>> classpath. Maven won't know that org.apache.commons:common-pool is >>>>>>>> the same as commons-pool:commons-pool, so it would potentially put >>>>>>>> both on the classpath. I believe there are also binary compatibility >>>>>>>> issues (hence the 2.0), so changing that would mean we'd want to >>>>>>>> change it also. >>>>>>>> >>>>>>>> On Fri, Oct 15, 2010 at 2:34 PM, Phil Steitz<phil.ste...@gmail.com> >>> wrote: >>>>>>>>> +1 for 2.0. We should also talk about the ugliness that we should >>> probably also do for 2.0: o.a.c.pool2 or somesuch. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Oct 15, 2010, at 12:20 PM, Simone Tripodi< >>> simone.trip...@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hi all mates, >>>>>>>>>> is this the right time to move the pool grouId to >>> org.apache.commons? >>>>>>>>>> Many thanks in advance, >>>>>>>>>> Simo >>>>>>>>>> >>>>>>>>>> http://people.apache.org/~simonetripodi/ >>>>>>>>>> http://www.99soft.org/ >>>>>>>>>> >>>>>>>>>> >>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>>>> >>>>>>>>> >>>>>>>>> > --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Dennis Lundberg >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>>> >>>> >>>> -- >>>> Dennis Lundberg >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
