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.
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
