You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Emmanuel Bourg <eb...@apache.org> on 2013/05/28 12:58:11 UTC
Re: [dbcp] update DBCP2 to require JDBC 4.1 (Java 7) WAS svn commit:
r1431496 - in /commons/proper/dbcp/trunk: ./ src/java/org/apache/commons/dbcp2/
src/java/org/apache/commons/dbcp2/cpdsadapter/ src/java/org/apache/commons/dbcp2/datasources/
src/test/org/apache/commons/dbcp2/ src/test/org/apache/commons/dbc...
Le 11/01/2013 08:36, Mark Thomas a écrit :
> We could also add the JDBC 4.1 methods to DBCP1 but I'm not sure I like the idea of three builds for that version.
I think we should do that. Debian and Fedora maintain a patch to be able
to build DBCP from source (see DBCP-385), but we should assume this burden.
I see 3 options, either:
1. Release DBCP 1.4.1 with no-op methods throwing a
SQLFeatureNotSupportedException or an UnsupportedOperationException.
This is what Fedora/Debian do.
2. Release DBCP 1.5 with the fully implemented methods and Java 7 as a
build requirement.
3. Release DBCP 1.4.1 or 1.5 with the fully implemented methods but
using reflection, thus compiling with Java 6 or Java 7.
What do you think ?
Emmanuel Bourg
Re: [dbcp] update DBCP2 to require JDBC 4.1 (Java 7) WAS svn commit:
r1431496 - in /commons/proper/dbcp/trunk: ./ src/java/org/apache/commons/dbcp2/
src/java/org/apache/commons/dbcp2/cpdsadapter/ src/java/org/apache/commons/dbcp2/datasources/
src/test/org/apache/commons/dbcp2/ src/test/org/apache/commons/dbc...
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, May 28, 2013 at 6:58 AM, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 11/01/2013 08:36, Mark Thomas a écrit :
>
> > We could also add the JDBC 4.1 methods to DBCP1 but I'm not sure I like
> the idea of three builds for that version.
>
> I think we should do that. Debian and Fedora maintain a patch to be able
> to build DBCP from source (see DBCP-385), but we should assume this burden.
>
> I see 3 options, either:
>
> 1. Release DBCP 1.4.1 with no-op methods throwing a
> SQLFeatureNotSupportedException or an UnsupportedOperationException.
> This is what Fedora/Debian do.
>
That's fine with me but I would not say this is not for a maintenance
version, it should be for a minor version.
> 2. Release DBCP 1.5 with the fully implemented methods and Java 7 as a
> build requirement.
>
Fine with me, nice and simple.
>
> 3. Release DBCP 1.4.1 or 1.5 with the fully implemented methods but
> using reflection, thus compiling with Java 6 or Java 7.
>
I do not like these kinds of solutions because I have to think twice about
what the dynamic behavior means on different platforms.
Gary
>
>
> What do you think ?
>
>
> Emmanuel Bourg
>
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [dbcp] update DBCP2 to require JDBC 4.1 (Java 7) WAS svn commit:
r1431496 - in /commons/proper/dbcp/trunk: ./ src/java/org/apache/commons/dbcp2/
src/java/org/apache/commons/dbcp2/cpdsadapter/ src/java/org/apache/commons/dbcp2/datasources/
src/test/org/apache/commons/dbcp2/ src/test/org/apache/commons/dbc...
Posted by Phil Steitz <ph...@gmail.com>.
On 5/30/13 4:06 AM, Emmanuel Bourg wrote:
> Le 30/05/2013 11:40, Phil Steitz a écrit :
>
>> Sorry for stupidity above. I was not thinking through the
>> consequences of the gump-esque build process. I guess if we really
>> want to support everything building from source with no binary
>> incompatible change, we are going to have to support the 1.x code
>> suitably hacked forward indefinitely. This is not a happy prospect;
>> but given how widely used DBCP is, we should do it. Given this, I
>> agree with your original proposal that we build in another layer of
>> filtering to the 1.x code base, with the no-op patch merged in. I
>> will play with this over the weekend and see if I can get an Ant
>> build working that extends what we do now to produce 1.3.x from the
>> 1.4.x sources to also source a 1.5.x.
OK, I played with this a little over the weekend and I think it is
doable. Before I start committing stuff, I want to make sure others
are OK with the following approach:
1. Create a new branch, DBCP_1_5_x. This will basically take the
role of DBCP_!_4_X, so once created *all code changes / bug fixes
for 1.x series should be applied only to the 1_5_x branch*.
2. Add the new methods (UOE-ed) to the 1_5_x sources, surrounded by
JDBC_4_1_ANT_KEY_BEGIN/END tags
3. Create build-1.4, pom-1.4 like the 1.3 versions, modifying 1.3
build to filter both, 1.4 only the 4.1 stuff.
4. Modify build.xml and the RC build process in release-process.txt
to handle the additional version.
The process gets a little more complicated, but I think it will work
and will allow us to avoid having to backport anything. The only
hitch that I see so far is that the process documented in
release-process.txt creates maven artifacts "manually" that I need
to figure out how to install without using the release plugin. Is
that still possible somehow?
If there are no objections to the setup above, I will create the 1.5
branch and add the JDBC4.1 methods and filter tags there.
Phil
> Thank you Phil.
>
> Hopefully this kind of maintenance happens only once every 2 years.
>
>
> Emmanuel Bourg
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] update DBCP2 to require JDBC 4.1 (Java 7) WAS svn commit:
r1431496 - in /commons/proper/dbcp/trunk: ./ src/java/org/apache/commons/dbcp2/
src/java/org/apache/commons/dbcp2/cpdsadapter/ src/java/org/apache/commons/dbcp2/datasources/
src/test/org/apache/commons/dbcp2/ src/test/org/apache/commons/dbc...
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 30/05/2013 11:40, Phil Steitz a écrit :
> Sorry for stupidity above. I was not thinking through the
> consequences of the gump-esque build process. I guess if we really
> want to support everything building from source with no binary
> incompatible change, we are going to have to support the 1.x code
> suitably hacked forward indefinitely. This is not a happy prospect;
> but given how widely used DBCP is, we should do it. Given this, I
> agree with your original proposal that we build in another layer of
> filtering to the 1.x code base, with the no-op patch merged in. I
> will play with this over the weekend and see if I can get an Ant
> build working that extends what we do now to produce 1.3.x from the
> 1.4.x sources to also source a 1.5.x.
Thank you Phil.
Hopefully this kind of maintenance happens only once every 2 years.
Emmanuel Bourg
Re: [dbcp] update DBCP2 to require JDBC 4.1 (Java 7) WAS svn commit:
r1431496 - in /commons/proper/dbcp/trunk: ./ src/java/org/apache/commons/dbcp2/
src/java/org/apache/commons/dbcp2/cpdsadapter/ src/java/org/apache/commons/dbcp2/datasources/
src/test/org/apache/commons/dbcp2/ src/test/org/apache/commons/dbc...
Posted by Phil Steitz <ph...@gmail.com>.
On 5/30/13 1:47 AM, Emmanuel Bourg wrote:
> Le 30/05/2013 06:12, Phil Steitz a écrit :
>
>> Only because we have not yet released 2.0. If we focus on doing
>> that, their problem is solved. That was basically my point above.
> Let's suppose we release a binary incompatible 2.0 version that compiles
> with Java 7, the Debian/Fedora maintainers will have to patch every
> packaged software that depends on DBCP 1.x to use the new API until the
> change is applied upstream (if ever it's applied). If the behavior of
> the API changed they'll also have to endorse the responsibility for
> testing their changes. That's worse than patching DBCP 1.x.
Sorry for stupidity above. I was not thinking through the
consequences of the gump-esque build process. I guess if we really
want to support everything building from source with no binary
incompatible change, we are going to have to support the 1.x code
suitably hacked forward indefinitely. This is not a happy prospect;
but given how widely used DBCP is, we should do it. Given this, I
agree with your original proposal that we build in another layer of
filtering to the 1.x code base, with the no-op patch merged in. I
will play with this over the weekend and see if I can get an Ant
build working that extends what we do now to produce 1.3.x from the
1.4.x sources to also source a 1.5.x.
Phil
>
>
>> Rather than hacking more compile filters so that 1.x can work for 3
>> different - incompatible - JDBC versions, we should split cleanly.
>> We are not that far away from being able to release 2.0. Then
>> whoever wants to target JDK 1.7 can use those sources.
> To avoid the proliferation of maintenance releases we may state that we
> support only the last two revisions of JDBC. Thus we would only support
> Java 7 (DBCP 1.5.x) and Java 6 (DBCP 1.4.x), and we abandon DBCP 1.3.
> Once Java 8 is released we drop Java 6 support (be it with DBCP 1.x or
> DBCP 2.x).
>
>
> Emmanuel Bourg
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] update DBCP2 to require JDBC 4.1 (Java 7) WAS svn commit:
r1431496 - in /commons/proper/dbcp/trunk: ./ src/java/org/apache/commons/dbcp2/
src/java/org/apache/commons/dbcp2/cpdsadapter/ src/java/org/apache/commons/dbcp2/datasources/
src/test/org/apache/commons/dbcp2/ src/test/org/apache/commons/dbc...
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 30/05/2013 06:12, Phil Steitz a écrit :
> Only because we have not yet released 2.0. If we focus on doing
> that, their problem is solved. That was basically my point above.
Let's suppose we release a binary incompatible 2.0 version that compiles
with Java 7, the Debian/Fedora maintainers will have to patch every
packaged software that depends on DBCP 1.x to use the new API until the
change is applied upstream (if ever it's applied). If the behavior of
the API changed they'll also have to endorse the responsibility for
testing their changes. That's worse than patching DBCP 1.x.
> Rather than hacking more compile filters so that 1.x can work for 3
> different - incompatible - JDBC versions, we should split cleanly.
> We are not that far away from being able to release 2.0. Then
> whoever wants to target JDK 1.7 can use those sources.
To avoid the proliferation of maintenance releases we may state that we
support only the last two revisions of JDBC. Thus we would only support
Java 7 (DBCP 1.5.x) and Java 6 (DBCP 1.4.x), and we abandon DBCP 1.3.
Once Java 8 is released we drop Java 6 support (be it with DBCP 1.x or
DBCP 2.x).
Emmanuel Bourg
Re: [dbcp] update DBCP2 to require JDBC 4.1 (Java 7) WAS svn commit:
r1431496 - in /commons/proper/dbcp/trunk: ./ src/java/org/apache/commons/dbcp2/
src/java/org/apache/commons/dbcp2/cpdsadapter/ src/java/org/apache/commons/dbcp2/datasources/
src/test/org/apache/commons/dbcp2/ src/test/org/apache/commons/dbc...
Posted by Phil Steitz <ph...@gmail.com>.
On 5/28/13 1:55 PM, Emmanuel Bourg wrote:
> Le 28/05/2013 21:47, Gary Gregory a écrit :
>
>> Something seems out of bounds here. Strictly speaking I know we deliver
>> sources and we provide a jar as a convenience.
>>
>> The source we deliver comes with a clear definition through the POM on how
>> to build it. We say, the source is Java version X and the target Java
>> version Y, where usually X=Y.
> Actually no, it doesn't say that. The source version is not an
> environment specification, it's a language level specification
> (5=generics, 6=@Override in interfaces, 7=Project Coin features, etc).
> And the target version specifies the compatible VMs. There is no
> assumption on the available libraries.
>
>
>> The safe thing to do as a builder is to build with a Java version that
>> matches the source version set in the POM.
> Sure that would be ideal, but that's not the reality. In the real world
> folks have to compile DBCP 1.x with Java 7 because they can't support
> Java 6 any longer.
Only because we have not yet released 2.0. If we focus on doing
that, their problem is solved. That was basically my point above.
Rather than hacking more compile filters so that 1.x can work for 3
different - incompatible - JDBC versions, we should split cleanly.
We are not that far away from being able to release 2.0. Then
whoever wants to target JDK 1.7 can use those sources.
>
>
>> The result of using a new Java version than that is undefined because who
>> knows what future JDKs will require.
> That's our responsibility as developers and maintainers to ensure our
> components are still usable with newer versions of Java. At least for
> the components with a significant user base, and DBCP is clearly one of
> them.
>
> Honestly, if we can't release a Java 7 compatible version of DBCP 1.x we
> should stop pretending that the source code is our primary deliverable,
> because this source code has been broken with the latest version of Java
> for nearly 2 years now.
That I agree with. I am willing to help out and review and apply
patches if we can assemble a few people to penetrate the dbcp2 code
(and the pool2 code it depends on). If others are not willing to
help, we should consider declaring it dormant. Just hacking the 1.x
sources to get things to compile is not real maintenance, IMO, so we
should either decide to actually move this thing forward or declare
it dormant.
Phil
>
>
> Emmanuel Bourg
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] update DBCP2 to require JDBC 4.1 (Java 7) WAS svn commit:
r1431496 - in /commons/proper/dbcp/trunk: ./ src/java/org/apache/commons/dbcp2/
src/java/org/apache/commons/dbcp2/cpdsadapter/ src/java/org/apache/commons/dbcp2/datasources/
src/test/org/apache/commons/dbcp2/ src/test/org/apache/commons/dbc...
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 28/05/2013 21:47, Gary Gregory a écrit :
> Something seems out of bounds here. Strictly speaking I know we deliver
> sources and we provide a jar as a convenience.
>
> The source we deliver comes with a clear definition through the POM on how
> to build it. We say, the source is Java version X and the target Java
> version Y, where usually X=Y.
Actually no, it doesn't say that. The source version is not an
environment specification, it's a language level specification
(5=generics, 6=@Override in interfaces, 7=Project Coin features, etc).
And the target version specifies the compatible VMs. There is no
assumption on the available libraries.
> The safe thing to do as a builder is to build with a Java version that
> matches the source version set in the POM.
Sure that would be ideal, but that's not the reality. In the real world
folks have to compile DBCP 1.x with Java 7 because they can't support
Java 6 any longer.
> The result of using a new Java version than that is undefined because who
> knows what future JDKs will require.
That's our responsibility as developers and maintainers to ensure our
components are still usable with newer versions of Java. At least for
the components with a significant user base, and DBCP is clearly one of
them.
Honestly, if we can't release a Java 7 compatible version of DBCP 1.x we
should stop pretending that the source code is our primary deliverable,
because this source code has been broken with the latest version of Java
for nearly 2 years now.
Emmanuel Bourg
Re: [dbcp] update DBCP2 to require JDBC 4.1 (Java 7) WAS svn commit:
r1431496 - in /commons/proper/dbcp/trunk: ./ src/java/org/apache/commons/dbcp2/
src/java/org/apache/commons/dbcp2/cpdsadapter/ src/java/org/apache/commons/dbcp2/datasources/
src/test/org/apache/commons/dbcp2/ src/test/org/apache/commons/dbc...
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, May 28, 2013 at 3:24 PM, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 28/05/2013 19:50, Phil Steitz a écrit :
>
> > Looks complicated and painful. I would rather put energy into
> > getting dbcp 2.0 out the door and aim for the following:
> >
> > DBCP 1.3.x JDK 1.4-1.5
> > DBCP 1.4.x JDK 1.6
> > DBCP 2.x JDK 1.7
>
> Unfortunately that doesn't solve the issue for the Linux distros
> compiling everything from the source. They have to support softwares
> depending on DBCP 1.x, and as they move to Java 7 they will have to
> support DBCP 1.x with Java 7+ for some time.
>
Something seems out of bounds here. Strictly speaking I know we deliver
sources and we provide a jar as a convenience.
The source we deliver comes with a clear definition through the POM on how
to build it. We say, the source is Java version X and the target Java
version Y, where usually X=Y.
The safe thing to do as a builder is to build with a Java version that
matches the source version set in the POM.
The result of using a new Java version than that is undefined because who
knows what future JDKs will require.
I do not see a nice and clean solution aside from the one suggested by Phil.
Gary
>
>
> Emmanuel Bourg
>
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [dbcp] update DBCP2 to require JDBC 4.1 (Java 7) WAS svn commit:
r1431496 - in /commons/proper/dbcp/trunk: ./ src/java/org/apache/commons/dbcp2/
src/java/org/apache/commons/dbcp2/cpdsadapter/ src/java/org/apache/commons/dbcp2/datasources/
src/test/org/apache/commons/dbcp2/ src/test/org/apache/commons/dbc...
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 28/05/2013 19:50, Phil Steitz a écrit :
> Looks complicated and painful. I would rather put energy into
> getting dbcp 2.0 out the door and aim for the following:
>
> DBCP 1.3.x JDK 1.4-1.5
> DBCP 1.4.x JDK 1.6
> DBCP 2.x JDK 1.7
Unfortunately that doesn't solve the issue for the Linux distros
compiling everything from the source. They have to support softwares
depending on DBCP 1.x, and as they move to Java 7 they will have to
support DBCP 1.x with Java 7+ for some time.
Emmanuel Bourg
Re: [dbcp] update DBCP2 to require JDBC 4.1 (Java 7) WAS svn commit:
r1431496 - in /commons/proper/dbcp/trunk: ./ src/java/org/apache/commons/dbcp2/
src/java/org/apache/commons/dbcp2/cpdsadapter/ src/java/org/apache/commons/dbcp2/datasources/
src/test/org/apache/commons/dbcp2/ src/test/org/apache/commons/dbc...
Posted by Phil Steitz <ph...@gmail.com>.
On 5/28/13 3:58 AM, Emmanuel Bourg wrote:
> Le 11/01/2013 08:36, Mark Thomas a écrit :
>
>> We could also add the JDBC 4.1 methods to DBCP1 but I'm not sure I like the idea of three builds for that version.
> I think we should do that. Debian and Fedora maintain a patch to be able
> to build DBCP from source (see DBCP-385), but we should assume this burden.
>
> I see 3 options, either:
>
> 1. Release DBCP 1.4.1 with no-op methods throwing a
> SQLFeatureNotSupportedException or an UnsupportedOperationException.
> This is what Fedora/Debian do.
>
> 2. Release DBCP 1.5 with the fully implemented methods and Java 7 as a
> build requirement.
>
> 3. Release DBCP 1.4.1 or 1.5 with the fully implemented methods but
> using reflection, thus compiling with Java 6 or Java 7.
>
>
> What do you think ?
Looks complicated and painful. I would rather put energy into
getting dbcp 2.0 out the door and aim for the following:
DBCP 1.3.x JDK 1.4-1.5
DBCP 1.4.x JDK 1.6
DBCP 2.x JDK 1.7
The 1.4 branch (once the 1.7 stuff is reverted) can still be used to
generate 1.3 releases. Adding on another set of filters is in
theory possible, but painful.
So basically, we cut only pure maintenance releases for 1.3/1.4 and
put the energy into getting 2.0 out.
Phil
>
>
> Emmanuel Bourg
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org