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 Thu, 26 Nov 2009 11:11:42 GMT

Jörg Schaible wrote:
> Hi Grzegorz,
> Grzegorz Słowikowski wrote at Donnerstag, 26. November 2009 10:59:
> [snip]
>> Hi
>> I want to add something from myself, I think I'm experienced Maven user.
>> 1. As Paul said, when you have two different sources you should not try
>> to use classifiers
>> (I think technically it could be possible, but it is wrong way). There
>> are projects generating
>> two artifacts: base one and  jdk 1.4 compatible one. As i know, the
>> second one is generated from
>> the same classes as the first one using retrotranslator or retroweaver
>> plugin in the build process.
>> Subethasmtp is a good example:
> smtp/1.2/subethasmtp-smtp-1.2.pom
>> 2. I agree with Jorg that the JDBC3 version should be the natural
>> continuation of previous
>> versions, so commons-dbcp:commons-dbcp:1.3 would be for JDBC3, not JDBC4.
>> I know that Tomcat developers are waiting for new version of
>> commons-dbcp because of some leaks
>> in current commons-pool version (if I remember). Tomcat6 has Java5 as a
>> minimum. I thing, they
>> will not use jdbc4 version of commons-dbcp. If jdbc3 compatible version
>> will have different name
>> ("-jdbc3" suffix) you will have to answer millions of questions about it.
>> 3. The build process described here by Paul should work, but I don't
>> like the Maven+Ant hybrid.
>> Tomcat developers (again) will have problems, because they are
>> generating their "tomcat-dbcp.jar"
>> from commons-pool and commons-dbcp sources. They download these two
>> sources bundle,
>> change package names and merge them into one archive. If commons-dbcp
>> sources will be
>> jdbc4 compatible, they will have to repeat your 1. step above.
>> I wonder if it is possible to split commons-dbcp code base into two
>> modules and build them
>> entirely in Maven.
> You will always have an Ant task to perform the source generation of the 
> "conditional" compilation. The trunk builds only with JDBC4, the Ant task 
> has to run before building against JDBC3.
So I wrote about splitting the codebase into two modules. Lately I'm 
creating some library
with jdbc wrappers so I have the same problem. I wrote it against jdbc3 API.
Yesterday I have tested it against jdbc4. My solution it to create 
second module for jdbc4
with classes extending the ones in jdbc3 module with additional methods 
from jdbc4.
I've made two test modules: for java 1.5 and for Java 1.6 (enforced with 
Both test modules test both base modules and it works.

My modules:
jdbc3 - jdbc3 wrappers, module compiled with Java 1.5
jdbc4 - jdbc4 wrappers extending jdbc3 wrappers compiled with Java 1.6
java15-tests - tests for jdbc3 and jdbc4 modules compiled and run on 
Java 1.5
java16-tests - tests for jdbc3 and jdbc4 modules compiled and run on 
Java 1.6
Both java15-tests and java16-tests work so
it is possible to follow this way.

>> I made some simple tests. I could upload it somewhere
>> for you.
> You might use the -source artifact as dependency in the second module and 
> unpack it with the dependency plugin and use then the Ant task to prepare 
> the sources.
I don't like it, but technically it's trivial. You will have problems 
how to marriage it with IDE
> - Jörg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message