commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz SÅ‚owikowski <>
Subject Re: [dbcp] 1.3 release packaging - take two
Date Fri, 27 Nov 2009 08:04:25 GMT

Phil Steitz wrote:
> Niall Pemberton wrote:
> Good points - so what is your recommendation?
> org.apache.commons:commons-dbcp4:1.3
> commons-dbcp:commons-dbcp:1.3
> or
> org.apache.commons:commons-dbcp:1.3
> commons-dbcp:commons-dbcp:1.3
> or
> org.apache.commons:commons-dbcp:1.4
> commons-dbcp:commons-dbcp:1.3
> or?
> Phil
Think about war files, what you will have in WEB-INF/lib. You CANNOT 
have (accidentally,
from transitive dependencies) commons-dbcp and commond-dbcp4 together in 
the class path,
so the first proposal is not good.
If you release jdbc3 and jdbc4 artifacts from the same release process 
(some code commented for
jdbc3 version) - this is one release for me, so the version numbers 
should be identical.
But I see you will probably prefer releasing separately and creating 
branch for 1.3.x patch releases.
I would prefer this way too. In this situation we have version 1.3 
backward compatible and version
1.4 not compatible. Because incompatibility comes not from your API 
changes but from changes
inside Java API, then I say you don't have to change version numbering 
to 2.x.x (change on the
first position).
I don't remember what's going on inside Maven build of war artifact if 
you have two dependencies
with different group ids and the same artifact ids. They are different 
artifacts and there is no
version resolution between them. Maven war plugin prepares war content
in "target/{artifactId}-{version}" directory before creating war file, 
so one of these files will
overwrite the other I think.
If some other build tool would create war archive on the fly, both files 
could be packaged
because there are no constraints on unique file names inside jars/wars 
and this would be very bad!

Additionally I remember some discussions on Maven lists against 
relocations (some Apache
Commons project changed its groupId to "org.apache.commons", and 
reverted this change very
soon), but I don't remember the exact problem. Maybe you could ask Brett 
Porter or Jason val Zyl.

IMHO the safest and most conservative naming convention would be:


In this situation JDBC4 version always wins. It means you know what 
version will land in your
war file if you have both dependencies in your project and don't specify 
your preferred version
in the pom.xml file.


Grzegorz Slowikowski

> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message