2009/11/28 Phil Steitz <phil.ste...@gmail.com>:
> Niall Pemberton wrote:
>> 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
>
> I think adding this to the build.xml in trunk will be confusing. I
> agree with Sebb that if we do that we need to comment it. Since we
> are going to have to have a branch to cut the 1.3 release from and
> we also need to change the version number in the build files there,
> I was thinking it might be better to create a build.xml just for 1.3
> that eliminates the nojdbc4 stuff and executes the new goal as part
> of the build. I am pretty sure the filtering operation is
> idempotent, so should not be a problem executing repeatedly and this
> would eliminate the possibility of forgetting to do it. This and
> the modified (version change only) pom.xml would replace build.xml,
> pom.xml in the branch.
>
> The process for cutting 1.3.1/1.4.1 would then be
> 0) create a 1.3.1 branch from trunk
> 1) copy build.xml, pom.xml from 1.3 branch (alternatively, we could
> maintain build.xml.1.3, pom.xml.1.3 in trunk and rename in the branch).
> 2) backport any pom or build.xml changes from trunk to the 1.3
> versions in the branch
> 3) normal release stuff in trunk for 1.4, branch for 1.3
Sounds good to me. I don't mind either option for build.xml/pom.xml -
whichever you prefer.
Niall
> Phil
>
>>
>>> 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
