2009/11/28 Paul Benedict <pbened...@apache.org>: > I am recommending something unconventional here. We could include the > enforcer plug-in, in DBCP 1.4's POM, to enforce at least JDK 1.6 is > used. Just food for thought.
Its not necessary since setting the source/target JDK version to 1.6 will ensure DBCP 1.4 is built with a minimum of JDK 1.6 Niall > Paul > > On Fri, Nov 27, 2009 at 6:21 PM, Niall Pemberton > <niall.pember...@gmail.com> wrote: >> On Fri, Nov 27, 2009 at 9:46 PM, Jörg Schaible <joerg.schai...@gmx.de> wrote: >>> Hi Phil and Niall, >>> >>> Phil Steitz wrote: >>> >>>> Niall Pemberton wrote: >>>>> On Fri, Nov 27, 2009 at 10:45 AM, Jörg Schaible <joerg.schai...@gmx.de> >>>>> wrote: >>>>>> Hi Grzegorz, >>>>>> >>>>>> Grzegorz Słowikowski wrote at Freitag, 27. November 2009 10:45: >>>>>> >>>>>>> Hi Jorg >>>>>>> >>>>>>> Jörg Schaible wrote: >>>>>>>> Hi Grzegorz, >>>>>>>> >>>>>>>> Grzegorz Słowikowski wrote at Freitag, 27. November 2009 09:04: >>>>>> [snip] >>>>>> >>>>>>> I didn't thought about Maven in this sentence. For me generally it's >>>>>>> not good practice to create >>>>>>> two different artifacts (different artifactId) which cannot be present >>>>>>> in the classpath together. >>>>>> For sure, but the causing problem cannot be solved by any build tool. >>>>>> Look at the following situation: >>>>>> >>>>>> X - your project >>>>>> X depends on A and B >>>>>> A depends on dbcp-jdbc3 >>>>>> B depends on dbcp-jdbc4 >>>>>> >>>>>> Result: Your app is simply broken. It does not matter whether the build >>>>>> tool will place both dbcp jars into a shared library or only one of the >>>>>> jars and this is completely independent of the dbcp jar's names. >>>>> >>>>> I don't agree its not broken - its a normal situation. In this >>>>> scenario you use DBCP 1.4 and that should work just fine with both >>>>> dependency A and B. In maven terms it will do its normal dependency >>>>> resolution and pick the later DBCP version. >>>> >>>> I don't follow this - either the assertion that it will "work" or >>>> that maven will only include 1.4. IIUC, the "later version" >>>> resolution will only happen if we stick with the same groupId. >>>> Secondly, given the incompatibilities, the A part could blow up if >>>> dbcp 1.4 is used (of course, Jorg's point is that A and B are >>>> already incompatible in this case). >>> >>> I guess Niall has a point. However, look at this scenario with the example >>> above: >>> >>> X is using Java 6 >>> A has been build using Java 1.4 (hence JDBC 3) >>> B has been build using Java 6 >>> >>> The question is now whether the app is broken or not. Can X using A >>> successfully run on JDBC 4? >> >> Yes because nothing has been removed from JDBC 3 -> JDBC 4. Its no >> different from X is using Commons IO 1.4 and A was built using Commons >> IO 1.3 - can X using A successfully run with IO 1.4? As long as IO is >> backwards compatible then theres no problem - same for JDBC. There >> would have been screams by now if Apps built using JDBC 3 didn't work >> when moving to JDK 1.6 (and therefore JDBC 4) >> >> Niall >> >>> - 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
