On 28/11/2009, Niall Pemberton <niall.pember...@gmail.com> 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?
>
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-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
