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 (athena.apache.org: domain of sebbaz@gmail.com designates
 72.14.220.152 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=v4QX+oyZQX2+doJuHg/K9srh9cAy4+oZSk7aSxv3EAOOQhDUzHIj7D4AcKDW8UVfbO
         laAn7Z5K2enTIsbyeaqM67ZZRQ4ZOpYPZYkKHJ9eERUzJidiU/C3UQAqlULVuZda3h4L
         BV3TS7RS6O2N/gWdxDe/dlApEsPrVdwc3iqIc=
MIME-Version: 1.0
In-Reply-To: <55afdc850911280306s3200ea48x2baecf5e0d7a7d4@mail.gmail.com>
References: <4B0DA868.2090801@gmail.com> <4B0F8809.4040701@gmail.com>
	 <heo3nq$q0f$1@ger.gmane.org>
	 <55afdc850911270358s6a74dd8y4cca99a740e885fe@mail.gmail.com>
	 <4B0FFA5A.1000602@gmail.com>
	 <55afdc850911271049i17fee7e3k277f5ce7e828850c@mail.gmail.com>
	 <4B10460B.5080704@gmail.com>
	 <55afdc850911271616m6a03a947l19c580c38ec79e10@mail.gmail.com>
	 <4B10A0FF.2000207@gmail.com>
	 <55afdc850911280306s3200ea48x2baecf5e0d7a7d4@mail.gmail.com>
Date: Sat, 28 Nov 2009 14:39:22 +0000
Message-ID: <25aac9fc0911280639x7a2ea550o3f529b4457b111cf@mail.gmail.com>
Subject: Re: [dbcp] 1.3 release packaging - take two
From: sebb <sebbaz@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

On 28/11/2009, Niall Pemberton <niall.pemberton@gmail.com> wrote:
> 2009/11/28 Phil Steitz <phil.steitz@gmail.com>:
>
> > Niall Pemberton wrote:
>  >> 2009/11/27 Phil Steitz <phil.steitz@gmail.com>:
>  >>> Niall Pemberton wrote:
>  >>>> 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 C=
ANNOT
>  >>>>>>>> have (accidentally,
>  >>>>>>>> from transitive dependencies) commons-dbcp and commond-dbcp4 to=
gether in
>  >>>>>>>> the class path,
>  >>>>>>>> so the first proposal is not good.
>  >>>>>>> This can happen for all three proposals. Since the groupId is di=
fferent
>  >>>>>>> Maven handles the two artifacts in all three cases as unrelated.=
 If the
>  >>>>>>> artifact name for two distinct artifacts clash, it will automati=
cally
>  >>>>>>> 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 num=
bers
>  >>>>>>>> should be identical.
>  >>>>>>> Actually we have two incompatible versions. If someone depends (=
by
>  >>>>>>> transitive deps or directly) on both versions, he has always a p=
roblem.
>  >>>>>>> Changing the groupId for one will simply expose the problem more=
 obviously,
>  >>>>>>> because both jars will end up in the dependencies - otherwise Ma=
ven version
>  >>>>>>> resolution will silently chose one of them and drop the other on=
e.
>  >>>>>>>
>  >>>>>>>> But I see you will probably prefer releasing separately and cre=
ating
>  >>>>>>>> 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 nu=
mbering
>  >>>>>>>> to 2.x.x (change on the
>  >>>>>>>> first position).
>  >>>>>>>> I don't remember what's going on inside Maven build of war arti=
fact if
>  >>>>>>>> you have two dependencies
>  >>>>>>>> with different group ids and the same artifact ids. They are di=
fferent
>  >>>>>>>> artifacts and there is no
>  >>>>>>>> version resolution between them. Maven war plugin prepares war =
content
>  >>>>>>>> in "target/{artifactId}-{version}" directory before creating wa=
r 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, b=
oth files
>  >>>>>>>> could be packaged
>  >>>>>>>> because there are no constraints on unique file names inside ja=
rs/wars
>  >>>>>>>> and this would be very bad!
>  >>>>>>> Therefore we want to change the version for the JDBC version4, s=
o 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", an=
d
>  >>>>>>>> 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 b=
e:
>  >>>>>>>>
>  >>>>>>>> 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 w=
ith
>  >>>>>> the additional methods introduced by JDBC 4. How is this any diff=
erent
>  >>>>>> from any later version of a component that adds additional method=
s and
>  >>>>>> relies on the API of a later version of the JDK?
>  >>>>> The problem is that it is not backward compatible.  You can see th=
is
>  >>>>> 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 f=
or
>  >>>> 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 us=
ing
>  >>>> 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 JD=
K
>  >> 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 buil=
t
>  >> 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?
>

I think it needs a comment as to when to use it, as it changes the SVN
working copy, for example:

<!-- This target can be used to remove JDBC4-dependent code from the
current working copy e.g. in order to produce a JDBC3-only branch -->


>  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 the=
y
>  >>>>> 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 th=
e 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
>
>

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