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