commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: [DBCP] Possible strategy for multiple JDBC version support
Date Tue, 04 Jun 2013 10:43:56 GMT
Hi

Modules would make sense too (instead of classifier). 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.
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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message