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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
