commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [dbcp] 1.3 release packaging - take two
Date Thu, 26 Nov 2009 16:12:43 GMT
Jörg Schaible wrote:
> Hi Phil,
> Phil Steitz wrote at Donnerstag, 26. November 2009 15:20:
>> Jörg Schaible wrote:
> [snip]
>>> OK, but then we should really think about "drop-in replacement" or not.
>>> Basically we say that dbcp 1.3 with JDBC4 will not be backward
>>> compatible. Then why don't we use the new artifactId for this and allow
>>> 1.3 with JDBC3 to be a real drop-in replacement? If somebody works with
>>> ranges, he might get the newer dbcp anyway and wondering about the
>>> incompatibility later.
>>> Therefore we might better do:
>>> org.apache.commons:commons-dbcp4:1.3
>>> commons-dbcp:commons-dbcp:1.3
>> Thanks Jorg and Grzegorz.  Really appreciate the feedback. It is
>> important that we get this right, minimizing confusion / bad impact
>> to maven users and making upgrades both safe and as easy as
>> possible. I was thinking the same way as you, Jörg, on the groupId
>> change for the jdbc4 version.
> Note, that I also changed the artifactId "dbcp vs. dbcp4" ;-)
> However, thinking about it, I am not sure if this is necessary and we can 
> really keep the artifactId (your first plan). If somebody uses both 
> artifacts (by transitive deps), his project is broken anyway. We simply have 
> to point out in the website and README, that there are really two different 
> commons-dbcp-1.3.jar files. Or is it too much confusion?

That worries ma a little bit, more for Ant than Maven users.
Incompatible jars with the same name in the wild is asking for
trouble (well, like the old days ;).

Another option, given that we don't have to mess with relocation
poms, is just to use org.apache.commons:dbcp:1.3 for the jdbc4 version.


>> I see this as killing two birds with
>> one stone - getting us to the maven standard groupId moving forward
>> and eliminating or at least making less likely the chance of users
>> blowing up due to unintentional incompatible upgrades.
> Yes. And we can avoid the tedious relocation POMs, because it is no 
> relocation.
>> Regarding Tomcat, Mark or someone else can chime in to confirm, but
>> my understanding is that tomcat builds and repackages dbcp from
>> source using Ant and as long as we keep trunk sources as they are,
>> tomcat will be able to build all versions.
> - Jörg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message