You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2013/06/04 11:29:01 UTC
[DBCP] Possible strategy for multiple JDBC version support
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?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] Possible strategy for multiple JDBC version support
Posted by Jörg Schaible <Jo...@scalaris.com>.
Hi Phil,
Phil Steitz wrote:
[snip]
>> 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.
Nobody stops you from activating the profiles automatically based on the JDK
you let Maven run, but then it is not possible to run *Maven* with a
different JDK than the one that is used to compile the (filtered) source and
run the tests. It simply depends on what we want. The filtering itself is
still Ant, but automatically invoked by Maven.
> 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.
That's exactly what happens with the profile solution. One release for each
profile.
> 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?
We have a do-ocraty ;-)
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] Possible strategy for multiple JDBC version support
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 04/06/2013 16:01, Phil Steitz a écrit :
> Are you guys OK with me plowing forward with the setup I described
> yesterday
+1
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] Possible strategy for multiple JDBC version support
Posted by Phil Steitz <ph...@gmail.com>.
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
Re: [DBCP] Possible strategy for multiple JDBC version support
Posted by Jörg Schaible <Jo...@scalaris.com>.
Hi Sebb,
sebb wrote:
> On 4 June 2013 11:16, Jörg Schaible <Jo...@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?
Yes, because of the modified sourceDirectory setting. However, our assembly
creating the source distribution might have to be adjusted.
> I presume one would then just need to run the Maven build/deploy once
> for each JDBC version?
Right.
> Seems worth a try.
>
> Might also be worth considering using a classifier to distinguish the
> jars, rather than a version number?
Then you loose again the matching sources and javadoc artifacts. And from
customer's side you will have to add/modify/remove suddenly such a
classifier in case you're updating your Java runtime. Even more headache
with transitive dependencies, because then you might have more than one
artifact in the classpath and you cannot even exclude them separately,
because an exclusion can only be defined for all artifacts of
groupId:artifactId, you cannot specify a classifier. With version numbers
only, I can simply use a dependencyManagement section to select what I need.
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] Possible strategy for multiple JDBC version support
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 04/06/2013 16:23, Jörg Schaible a écrit :
> IMHO it is. If you do not have a matching -sources.jar, it will be
> cumbersome to debug a problem for any client. Note, that the -sources.jar
> would contain the filtered stuff, while the source distribution (-src.zip)
> would contain the originals.
Well, if the bytecode manipulation is done right I guess the proper line
numbers can be preserved. Thus the debugging wouldn't be affected.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] Possible strategy for multiple JDBC version support
Posted by Jörg Schaible <Jo...@scalaris.com>.
Emmanuel Bourg wrote:
> Le 04/06/2013 15:45, Phil Steitz a écrit :
>
>> Such a tool would be useful if it could automatically generate
>> taggable sources. This is what the comment markers and ant filter
>> tasks in the current setup do.
>
> I don't think a tool based on bytecode manipulation could produce the
> corresponding sources. The idea is to build the main jar with the latest
> JDK, and then strip or rewrite the methods from the .class files and
> generate new jars for the previous JDKs. Having the exact -sources or
> -javadoc artifacts that match the downgraded variants is not that
> important, they could be copied as is from the main artifact. It doesn't
> matter if they contain more methods than what is actually in the jar.
IMHO it is. If you do not have a matching -sources.jar, it will be
cumbersome to debug a problem for any client. Note, that the -sources.jar
would contain the filtered stuff, while the source distribution (-src.zip)
would contain the originals.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] Possible strategy for multiple JDBC version support
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 04/06/2013 15:45, Phil Steitz a écrit :
> Such a tool would be useful if it could automatically generate
> taggable sources. This is what the comment markers and ant filter
> tasks in the current setup do.
I don't think a tool based on bytecode manipulation could produce the
corresponding sources. The idea is to build the main jar with the latest
JDK, and then strip or rewrite the methods from the .class files and
generate new jars for the previous JDKs. Having the exact -sources or
-javadoc artifacts that match the downgraded variants is not that
important, they could be copied as is from the main artifact. It doesn't
matter if they contain more methods than what is actually in the jar.
Emmanuel Bourg
Re: [DBCP] Possible strategy for multiple JDBC version support
Posted by Phil Steitz <ph...@gmail.com>.
On 6/4/13 4:10 AM, Emmanuel Bourg wrote:
> Le 04/06/2013 13:03, sebb a écrit :
>
>> Are you sure?
>> Sounds like a lot more work than what we have currently.
> I like the idea. It's more work but the scope could be wider than DBCP.
> I guess any project implementing JDBC classes could be interested by a
> tool filtering JDBC methods and producing jars compatible with different
> JDKs.
Such a tool would be useful if it could automatically generate
taggable sources. This is what the comment markers and ant filter
tasks in the current setup do.
Phil
>
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> 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
Re: [DBCP] Possible strategy for multiple JDBC version support
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 04/06/2013 13:03, sebb a écrit :
> Are you sure?
> Sounds like a lot more work than what we have currently.
I like the idea. It's more work but the scope could be wider than DBCP.
I guess any project implementing JDBC classes could be interested by a
tool filtering JDBC methods and producing jars compatible with different
JDKs.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] Possible strategy for multiple JDBC version support
Posted by sebb <se...@gmail.com>.
On 4 June 2013 11:43, Romain Manni-Bucau <rm...@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" <se...@gmail.com> a écrit :
>
>> On 4 June 2013 11:16, Jörg Schaible <Jo...@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
Re: [DBCP] Possible strategy for multiple JDBC version support
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <se...@gmail.com> a écrit :
> On 4 June 2013 11:16, Jörg Schaible <Jo...@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
>
>
Re: [DBCP] Possible strategy for multiple JDBC version support
Posted by sebb <se...@gmail.com>.
On 4 June 2013 11:16, Jörg Schaible <Jo...@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
Re: [DBCP] Possible strategy for multiple JDBC version support
Posted by Jörg Schaible <Jo...@scalaris.com>.
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.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] Possible strategy for multiple JDBC version support
Posted by Jochen Wiedmann <jo...@gmail.com>.
Hi, Jörg,
On Wed, Jun 5, 2013 at 1:42 PM, Jörg Schaible
<Jo...@scalaris.com>wrote:
>
> This is here not possible, since we provide *implementations* that
> implement
> the affected interfaces. E.g. Statement interface has more methods which
> have arguments of types that are not even present in the older JDBC version
> i.e. you cannot even compile this source with the older JDK. Therefore all
> this filtering.
>
The problem is completely understood and I was just sketching a possibility
to circumvent it.
Jochen
--
"That's what prayers are ... it's frightened people trying to make friends
with the bully!"
Terry Pratchett. The Last Hero
Re: [DBCP] Possible strategy for multiple JDBC version support
Posted by Jörg Schaible <Jo...@scalaris.com>.
Hi Jochen,
Jochen Wiedmann wrote:
> On Tue, Jun 4, 2013 at 11:29 AM, sebb <se...@gmail.com> 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).
>>
>
> Alternative proposal (worked for me in the past in similar situations):
>
> Create the instances of Connection, Statement, etc. using
> java.lang.reflect.Proxy, with a suitable InvocationHandler. The instances
> generated by Proxy are implementing the runtime version of the respective
> interface, hence no compatibility problems. The InvocationHandler doesn't
> implement anything, hence can adjust its behaviour at runtime to the
> proper JDBC version.
This is here not possible, since we provide *implementations* that implement
the affected interfaces. E.g. Statement interface has more methods which
have arguments of types that are not even present in the older JDBC version
i.e. you cannot even compile this source with the older JDK. Therefore all
this filtering.
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] Possible strategy for multiple JDBC version support
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Tue, Jun 4, 2013 at 11:29 AM, sebb <se...@gmail.com> 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).
>
Alternative proposal (worked for me in the past in similar situations):
Create the instances of Connection, Statement, etc. using
java.lang.reflect.Proxy, with a suitable InvocationHandler. The instances
generated by Proxy are implementing the runtime version of the respective
interface, hence no compatibility problems. The InvocationHandler doesn't
implement anything, hence can adjust its behaviour at runtime to the proper
JDBC version.
Jochen
--
"That's what prayers are ... it's frightened people trying to make friends
with the bully!"
Terry Pratchett. The Last Hero
Re: [DBCP] Possible strategy for multiple JDBC version support
Posted by Phil Steitz <ph...@gmail.com>.
On 6/4/13 2:29 AM, 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]
That is sort of true. In trunk, are aiming for JDBC 4.1. and DBCP
2.0. Then we have the "compatibility branches" that are backward
compatible from DBCP standpoint with 1.x versions. The note I
posted yesterday describes the current sightly broken setup and what
I propose moving forward - basically that where is a "source" branch
that supports JDBC 4.1 and automatically-generated tag preimages for
the 4 and 3.
>
> Previous versions are currently built and deployed using Ant which has
> to pre-process the source before doing the build.
All that Ant is used for really is the source filtering. The actual
release artifacts are generated using maven.
>
> 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.
That's what the current setup does. See release-process.txt in the
compat branch.
> 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?
Yes. That is basically what I proposed yesterday, extending the
process that was used to create DBCP 1.3 and 1.4. There is one
wrinkle, which causes the other compat branches to be created and
that is that the version-specific build files need to be renamed in
the branches. Since at least I like to see tags as immutable, I
create the branch, make the build file change and then create the
tag from it.
Phil
>
> ---------------------------------------------------------------------
> 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