Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of niall.pemberton@gmail.com
 designates 209.85.220.209 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=paCFrPT8S3xnvNWLnBt9/qai6BYkPdJIEFKEKnJZtmq7bIFpql4oka0rOpZtXy2IIE
         wG7vh2X66CWfJWONPSMgGQvdaSI9qJ+J/maY2bownNjrdn866tCqfWAPEFNC7TffHcC3
         /+ZqxwI2uk8pLNuD3mmmszucLVZXhkNoYxDa8=
MIME-Version: 1.0
In-Reply-To: <4B0FFA5A.1000602@gmail.com>
References: <4B0DA868.2090801@gmail.com> <4B0EA8FB.8040507@gmail.com>
	 <hema9r$hsj$1@ger.gmane.org> <4B0EAF2D.6020403@gmail.com>
	 <55afdc850911260901v2511adddpe1eacd73fb50e7c7@mail.gmail.com>
	 <4B0EBDBE.3000300@gmail.com> <4B0F8809.4040701@gmail.com>
	 <heo3nq$q0f$1@ger.gmane.org>
	 <55afdc850911270358s6a74dd8y4cca99a740e885fe@mail.gmail.com>
	 <4B0FFA5A.1000602@gmail.com>
Date: Fri, 27 Nov 2009 18:49:23 +0000
Message-ID: <55afdc850911271049i17fee7e3k277f5ce7e828850c@mail.gmail.com>
Subject: Re: [dbcp] 1.3 release packaging - take two
From: Niall Pemberton <niall.pemberton@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

2009/11/27 Phil Steitz <phil.steitz@gmail.com>:
> Niall Pemberton wrote:
>> On Fri, Nov 27, 2009 at 8:47 AM, J=F6rg Schaible <joerg.schaible@gmx.de>=
 wrote:
>>> Hi Grzegorz,
>>>
>>> Grzegorz S=B3owikowski 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 obviou=
sly,
>>> because both jars will end up in the dependencies - otherwise Maven ver=
sion
>>> 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 fil=
es
>>>> 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 en=
d up
>>> for those tools with two distinguishable names: commons-dbcp-1.3.jar an=
d
>>> 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 Bre=
tt
>>>> 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. =A0You can see this
> using the test-jar.xml ant build in trunk. =A0Build 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

Niall

> jar using 1.4 or 1.5 and you will get runtime errors. =A0Sebb 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 speci=
fy
>>>> 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=F6rg

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