commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [DBCP] Possible strategy for multiple JDBC version support
Date Tue, 04 Jun 2013 13:55:23 GMT
On 6/4/13 2:29 AM, sebb wrote:
> DBCP is complicated to release, because the source has to be
> pre-processed in order to build additional versions of the code.
> (unlike the rest of Java, JDBC is not generally upwards compatible).
> The source code in SVN is for the latest JDBC version we support, and
> can be built and deployed using Maven the same as any other normal
> Commons component.
> [At least I assume that is the case; if not that ought to be fixed first]

That is sort of true.  In trunk, are aiming for JDBC 4.1. and DBCP
2.0.  Then we have the "compatibility branches" that are backward
compatible from DBCP standpoint with 1.x versions.  The note I
posted yesterday describes the current sightly broken setup and what
I propose moving forward - basically that where is a "source" branch
that supports JDBC 4.1 and automatically-generated tag preimages for
the 4 and 3.

> Previous versions are currently built and deployed using Ant which has
> to pre-process the source before doing the build.

All that Ant is used for really is the source filtering.  The actual
release artifacts are generated using maven.
> Now component RCs should ideally be built from a fresh checkout of the
> tag, so one possible approach would be to use Ant to create the tag
> and workspace and then use Maven as before.

That's what the current setup does.  See release-process.txt in the
compat branch.

> It would mean using multiple workspaces, but it does not take huge
> amounts of disk space.
> The process for previous JDBC versions would be:
> Checkout a fresh workspace from SVN.
> Run Ant to fix up the source code
> Create the RC tag directly from the workspace
> Use Maven to build and deploy the jars.
> Does that sound like a possible approach?

Yes. That is basically what I proposed yesterday, extending the
process that was used to create DBCP 1.3 and 1.4.  There is one
wrinkle, which causes the other compat branches to be created and
that is that the version-specific build files need to be renamed in
the branches.  Since at least I like to see tags as immutable, I
create the branch, make the build file change and then create the
tag from it.

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

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

View raw message