commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [pool] time to move groupId?
Date Sat, 16 Oct 2010 14:45:19 GMT
On Sat, Oct 16, 2010 at 10:25 AM, James Carman
<james@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.steitz@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"<dennisl@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<dennisl@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
>>>>>>> <james@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.steitz@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.tripodi@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-unsubscribe@commons.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Dennis Lundberg
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Dennis Lundberg
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message