Re: [DBCP] Possible strategy for multiple JDBC version support

2013-06-05 Thread Jochen Wiedmann
Hi, Jörg, On Wed, Jun 5, 2013 at 1:42 PM, Jörg Schaible 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 versi

Re: [DBCP] Possible strategy for multiple JDBC version support

2013-06-05 Thread Jörg Schaible
Hi Jochen, Jochen Wiedmann wrote: > On Tue, Jun 4, 2013 at 11: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). >> > >

Re: [DBCP] Possible strategy for multiple JDBC version support

2013-06-05 Thread Jochen Wiedmann
On Tue, Jun 4, 2013 at 11: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). > Alternative proposal (worked for me in the past

Re: [DBCP] Possible strategy for multiple JDBC version support

2013-06-04 Thread Emmanuel Bourg
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 original

Re: [DBCP] Possible strategy for multiple JDBC version support

2013-06-04 Thread Jörg Schaible
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 c

Re: [DBCP] Possible strategy for multiple JDBC version support

2013-06-04 Thread Emmanuel Bourg
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-unsubscr...@commons.apache.org For additional commands

Re: [DBCP] Possible strategy for multiple JDBC version support

2013-06-04 Thread Jörg Schaible
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 /

Re: [DBCP] Possible strategy for multiple JDBC version support

2013-06-04 Thread Emmanuel Bourg
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 sou

Re: [DBCP] Possible strategy for multiple JDBC version support

2013-06-04 Thread Phil Steitz
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

Re: [DBCP] Possible strategy for multiple JDBC version support

2013-06-04 Thread Phil Steitz
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 suppor

Re: [DBCP] Possible strategy for multiple JDBC version support

2013-06-04 Thread Phil Steitz
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

Re: [DBCP] Possible strategy for multiple JDBC version support

2013-06-04 Thread Jörg Schaible
Hi Sebb, sebb wrote: > On 4 June 2013 11:16, 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). >>> >

Re: [DBCP] Possible strategy for multiple JDBC version support

2013-06-04 Thread Emmanuel Bourg
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 j

Re: [DBCP] Possible strategy for multiple JDBC version support

2013-06-04 Thread sebb
On 4 June 2013 11:43, Romain Manni-Bucau 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 a

Re: [DBCP] Possible strategy for multiple JDBC version support

2013-06-04 Thread Romain Manni-Bucau
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" a écrit : > On 4 June 2013 11:16, Jörg Schaible wrote: > > sebb wro

Re: [DBCP] Possible strategy for multiple JDBC version support

2013-06-04 Thread sebb
On 4 June 2013 11:16, 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

Re: [DBCP] Possible strategy for multiple JDBC version support

2013-06-04 Thread Jörg Schaible
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 b

[DBCP] Possible strategy for multiple JDBC version support

2013-06-04 Thread sebb
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 M