commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [DBCP] Possible strategy for multiple JDBC version support
Date Tue, 04 Jun 2013 11:03:54 GMT
On 4 June 2013 11:43, Romain Manni-Bucau <rmannibucau@gmail.com> wrote:
> Hi
>
> Modules would make sense too (instead of classifier).

I don't think so, because the builds all need different compilers and libraries.

Also Maven modules are tricky to get right for site builds and seems
overkill here.

> That said using asm
> to generate classes for older versions would be simple enough to get a
> single artifact with N impl in different packages.

Are you sure?
Sounds like a lot more work than what we have currently.

> Le 4 juin 2013 12:39, "sebb" <sebbaz@gmail.com> a écrit :
>
>> On 4 June 2013 11:16, Jörg Schaible <Joerg.Schaible@scalaris.com> 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:
>>
>> Would the generated source jars contain the updated source?
>> Ditto Javadoc?
>>
>> I presume one would then just need to run the Maven build/deploy once
>> for each JDBC version?
>>
>> Seems worth a try.
>>
>> Might also be worth considering using a classifier to distinguish the
>> jars, rather than a version number?
>>
>> > ========= %< ===========
>> >  <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.
>> >
>> > - 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
>>
>>

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


Mime
View raw message