2009/11/28 Phil Steitz <phil.ste...@gmail.com>:
> Niall Pemberton wrote:
>> 2009/11/27 Phil Steitz <phil.ste...@gmail.com>:
>>> 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.
>>
>> For a project to depend on DBCP 1.4 then they will have to require JDK
>> 1.6. Anyone who depends on that project will also therefore have to
>> require JDK 1.6. I guess its probably possible to have a project built
>> on JDK 1.6, but with a source/target set to a previous JDK and a
>> dependency on DBCP 1.4 - but this is broken since with DBCP 1.4 it
>> will (as you say) only ever run on JDK 1.6.
>>
>> Anyway, this is just a build issue that someone will have to sort out.
>> If that could happen (which tbh I doubt) then they will just have to
>> revert back to DBCP 1.3. This is true of any of our components that
>> have "upgraded" their minimum JDK requirements. In this scenario
>> though its not an issue because we will be providing a DBCP 1.3
>> solution that they can revert to that has all the fixes of DBCP 1.4,
>> just without the JDBC 4 features.
>>
>
> Thanks, Niall. Sorry I was not clear and a little slow to come
> around to seeing the full picture here. I now understand and agree
> with the approach - including not changing the groupId - that you
> have proposed. I have a couple of small things to fix and then I
> will cut RCs for both 1.3 and 1.4.
Great, let me know if theres anything you want me to do to help.
When I created a test branch I added the following step to the ant
build file to update the sources in place:
http://tinyurl.com/ykhafzb
Should we add this to build.xml in trunk?
Niall
> Phil
>
>>> 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
