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" <seb...@gmail.com> a écrit :
> On 4 June 2013 11:16, Jörg Schaible <joerg.schai...@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-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
