Niall Pemberton wrote:
> 2009/11/27 Phil Steitz <phil.ste...@gmail.com>:
>> Niall Pemberton wrote:
>>> On Fri, Nov 27, 2009 at 8:47 AM, Jörg Schaible <joerg.schai...@gmx.de>
>>> wrote:
>>>> Hi Grzegorz,
>>>>
>>>> Grzegorz Słowikowski wrote at Freitag, 27. November 2009 09:04:
>>>>
>>>>> Phil Steitz wrote:
>>>>>> Niall Pemberton wrote:
>>>>>>
>>>>> ...
>>>>>> Good points - so what is your recommendation?
>>>>>>
>>>>>> org.apache.commons:commons-dbcp4:1.3
>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>
>>>>>> or
>>>>>>
>>>>>> org.apache.commons:commons-dbcp:1.3
>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>
>>>>>> or
>>>>>>
>>>>>> org.apache.commons:commons-dbcp:1.4
>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>
>>>>>> or?
>>>>>>
>>>>>>
>>>>>> Phil
>>>>>>
>>>>> ...
>>>>> Think about war files, what you will have in WEB-INF/lib. You CANNOT
>>>>> have (accidentally,
>>>>> from transitive dependencies) commons-dbcp and commond-dbcp4 together in
>>>>> the class path,
>>>>> so the first proposal is not good.
>>>> This can happen for all three proposals. Since the groupId is different
>>>> Maven handles the two artifacts in all three cases as unrelated. If the
>>>> artifact name for two distinct artifacts clash, it will automatically
>>>> prepend the groupId for such cases like the war plugin.
>>>>
>>>>
>>>>> If you release jdbc3 and jdbc4 artifacts from the same release process
>>>>> (some code commented for
>>>>> jdbc3 version) - this is one release for me, so the version numbers
>>>>> should be identical.
>>>> Actually we have two incompatible versions. If someone depends (by
>>>> transitive deps or directly) on both versions, he has always a problem.
>>>> Changing the groupId for one will simply expose the problem more obviously,
>>>> because both jars will end up in the dependencies - otherwise Maven version
>>>> resolution will silently chose one of them and drop the other one.
>>>>
>>>>> But I see you will probably prefer releasing separately and creating
>>>>> branch for 1.3.x patch releases.
>>>>> I would prefer this way too. In this situation we have version 1.3
>>>>> backward compatible and version
>>>>> 1.4 not compatible. Because incompatibility comes not from your API
>>>>> changes but from changes
>>>>> inside Java API, then I say you don't have to change version numbering
>>>>> to 2.x.x (change on the
>>>>> first position).
>>>>> I don't remember what's going on inside Maven build of war artifact if
>>>>> you have two dependencies
>>>>> with different group ids and the same artifact ids. They are different
>>>>> artifacts and there is no
>>>>> version resolution between them. Maven war plugin prepares war content
>>>>> in "target/{artifactId}-{version}" directory before creating war file,
>>>>> so one of these files will
>>>>> overwrite the other I think.
>>>> As explained - no.
>>>>
>>>>> If some other build tool would create war archive on the fly, both files
>>>>> could be packaged
>>>>> because there are no constraints on unique file names inside jars/wars
>>>>> and this would be very bad!
>>>> Therefore we want to change the version for the JDBC version4, so we end up
>>>> for those tools with two distinguishable names: commons-dbcp-1.3.jar and
>>>> commons-dbcp-1.4.jar
>>>>
>>>>> Additionally I remember some discussions on Maven lists against
>>>>> relocations (some Apache
>>>>> Commons project changed its groupId to "org.apache.commons", and
>>>>> reverted this change very
>>>>> soon), but I don't remember the exact problem. Maybe you could ask Brett
>>>>> Porter or Jason val Zyl.
>>>> No relocations involved here.
>>>>
>>>>> IMHO the safest and most conservative naming convention would be:
>>>>>
>>>>> commons-dbcp:commons-dbcp:1.4
>>>>> commons-dbcp:commons-dbcp:1.3
>>>> No, because this would actually make the JDBC4 version available as an
>>>> upgrade for the JDBC3 one. This is the scenario we have to avoid.
>>> I really don't understand this - this is exactly the scenario we want.
>>> Doing it this way DBCP 1.4 will just be an upgrade for DBCP 1.3 with
>>> the additional methods introduced by JDBC 4. How is this any different
>>> from any later version of a component that adds additional methods and
>>> relies on the API of a later version of the JDK?
>> The problem is that it is not backward compatible. You can see this
>> using the test-jar.xml ant build in trunk. Build a jar using JDK
>> 1.6 and then try to build the tests and execute them against this
>
> I did, with the source/target set to JDK 1.6 - so the minimum JDK for
> DBCP 1.4 is JDK 1.6. That way anyone who wants to depend on DBCP 1.4
> will have to be on JDK 1.6. The mistake IMO is to build DBCP 1.4 using
> JDK 1.6 while setting the source/traget JDK to < JDK 1.6
>
Agreed, but those on 1.4 or 1.5 will still get runtime errors if
they inadvertently get "upgraded" unless I am missing something
here. Running against the 1.4 jar you posted, I now get bad class
file errors.
Phil
> Niall
>
>> jar using 1.4 or 1.5 and you will get runtime errors. Sebb chased
>>
>> at least one of these down as being due to an import
>> (SQLClientInfoException) in the jdbc4 code.
>>
>> That is the reason I proposed changing the groupId, because I did
>> not want client apps to blow up with runtime errors when "latest
>> version" resolution of range specifiers grab 1.4 for them when they
>> are running jdk 1.4 or 1.5.
>>
>> Phil
>>> Niall
>>>
>>>>> In this situation JDBC4 version always wins. It means you know what
>>>>> version will land in your
>>>>> war file if you have both dependencies in your project and don't specify
>>>>> your preferred version
>>>>> in the pom.xml file.
>>>> No, if you know what you need, you can adjust the groupId for the JDBC4
>>>> version. If your dependencies still contains the other one, you have a
>>>> problem anyway.
>>>>
>>>> - 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
