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

Reply via email to