On 4 June 2013 11:43, Romain Manni-Bucau <rmannibu...@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" <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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
