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? - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
