commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [DBCP] Possible strategy for multiple JDBC version support
Date Tue, 04 Jun 2013 14:01:38 GMT
On 6/4/13 3:16 AM, Jörg Schaible wrote:
> 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]
>>
>> Previous versions are currently built and deployed using Ant which has
>> to pre-process the source before doing the build.
>>
>> 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.
>> 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?
> Why not use the antrun plugin in a profile in the generate-sources phase to 
> filter the sources into a new directory in target/generates-sources and also 
> set the path to the Java source in that profile to this directory? You can 
> even reuse our existing profiles for the Java runtime:
>
> ========= %< ===========
>  <build>
>    <sourceDirectory>${dbcp.source.directory}</sourceDirectory>
>  </build>
>  <profiles>
>    <profile>
>      <id>jdk-1.5</id>
>      <build>
>        <plugins>
>          <plugin>
>            <artifactId>maven-antrun-plugin</artifactId>
>            <executions>
>              <execution>
>                <id>filter-out-jdbc4</id>
>                <phase>generate-sources</phase>
>                <goals>
>                  <goal>run</goal>
>                </goals>
>              </execution>
>            </executions>
>            <configuration>
>  <!- filter sources into target/generated-sources/java ->
>            </configuration>
>          </plugin>
>        </plugins>
>      </build>
>      <properties>
>        <dbcp.source.directory>target/generated-
> sources/java</db.source.directory>
>      </properties>
>    </profile>
>  </profiles>
>  <properties>
>    <dbcp.source.directory>src/main/java</db.source.directory>
>  </properties>
> ========= %< ===========
>
> For the release you can now activate the appropriate JDK profile, provide 
> the versions with the command line and possibly we can additionally add an 
> enforcer rule to avoid errors.

If maven can do the filtering to help create the source branches /
tags, that could eliminate the need to run Ant separately; but there
is also a nice feature of the Ant build that makes testing easier -
it can detect JDK levels and filter dynamically, so you can get all
of them working before you start splitting things out.  A key thing
we have to remember is that for each version, we need a tag that
corresponds exactly to what is released in that version and the
source in that tag has to build using the target JDK.

Are you guys OK with me plowing forward with the setup I described
yesterday - basically extending the Ant filtering - or should I hold
off creating the 1.5 branch and adding the filter tags?

Phil
>
> - Jörg
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message