commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [dbcp] 1.3 release packaging - take two
Date Sat, 28 Nov 2009 14:39:22 GMT
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örg Schaible <joerg.schaible@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?
>

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
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-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


Mime
View raw message