On Sat, Oct 16, 2010 at 10:25 AM, 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? >
I'll answer my own question. With this pom.xml file: <project xmlns="http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd";> <modelVersion>4.0.0</modelVersion> <groupId>maven.test</groupId> <artifactId>jarhell</artifactId> <version>1.0-SNAPSHOT</version> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.8.1</version> <scope>test</scope> </dependency> </dependencies> </project> I get the following output when I run mvn dependency:list: [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'dependency'. [INFO] ------------------------------------------------------------------------ [INFO] Building Unnamed - maven.test:jarhell:jar:1.0-SNAPSHOT [INFO] task-segment: [dependency:list] [INFO] ------------------------------------------------------------------------ [INFO] [dependency:list {execution: default-cli}] [INFO] [INFO] The following files have been resolved: [INFO] junit:junit:jar:4.8.1:test [INFO] [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 3 seconds [INFO] Finished at: Sat Oct 16 10:44:12 EDT 2010 [INFO] Final Memory: 20M/254M [INFO] ------------------------------------------------------------------------ So, it doesn't allow two dependencies with the same group/artifact id, which is why we decided to change the artifact id also. > 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
