commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Benedict <pbened...@apache.org>
Subject Re: [dbcp] 1.3 release packaging - take two
Date Sat, 28 Nov 2009 01:11:17 GMT
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.pemberton@gmail.com> wrote:
> On Fri, Nov 27, 2009 at 9:46 PM, Jörg Schaible <joerg.schaible@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.schaible@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message