[dbcp] 1.3 release packaging - take two

classic Classic list List threaded Threaded
68 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Niall Pemberton
2009/11/28 Paul Benedict <[hidden email]>:
> I am recommending something unconventional here. We could include the
> enforcer plug-in, in DBCP 1.4's POM, to enforce at least JDK 1.6 is
> used. Just food for thought.

Its not necessary since setting the source/target JDK version to 1.6
will ensure DBCP 1.4 is built with a minimum of JDK 1.6

Niall

> Paul
>
> On Fri, Nov 27, 2009 at 6:21 PM, Niall Pemberton
> <[hidden email]> wrote:
>> On Fri, Nov 27, 2009 at 9:46 PM, Jörg Schaible <[hidden email]> wrote:
>>> Hi Phil and Niall,
>>>
>>> Phil Steitz wrote:
>>>
>>>> Niall Pemberton wrote:
>>>>> On Fri, Nov 27, 2009 at 10:45 AM, Jörg Schaible <[hidden email]>
>>>>> wrote:
>>>>>> Hi Grzegorz,
>>>>>>
>>>>>> Grzegorz Słowikowski wrote at Freitag, 27. November 2009 10:45:
>>>>>>
>>>>>>> Hi Jorg
>>>>>>>
>>>>>>> Jörg Schaible wrote:
>>>>>>>> Hi Grzegorz,
>>>>>>>>
>>>>>>>> Grzegorz Słowikowski wrote at Freitag, 27. November 2009 09:04:
>>>>>> [snip]
>>>>>>
>>>>>>> I didn't thought about Maven in this sentence. For me generally it's
>>>>>>> not good practice to create
>>>>>>> two different artifacts (different artifactId) which cannot be present
>>>>>>> in the classpath together.
>>>>>> For sure, but the causing problem cannot be solved by any build tool.
>>>>>> Look at the following situation:
>>>>>>
>>>>>> X - your project
>>>>>> X depends on A and B
>>>>>> A depends on dbcp-jdbc3
>>>>>> B depends on dbcp-jdbc4
>>>>>>
>>>>>> Result: Your app is simply broken. It does not matter whether the build
>>>>>> tool will place both dbcp jars into a shared library or only one of the
>>>>>> jars and this is completely independent of the dbcp jar's names.
>>>>>
>>>>> I don't agree its not broken - its a normal situation. In this
>>>>> scenario you use DBCP 1.4 and that should work just fine with both
>>>>> dependency A and B. In maven terms it will do its normal dependency
>>>>> resolution and pick the later DBCP version.
>>>>
>>>> I don't follow this - either the assertion that it will "work" or
>>>> that maven will only include 1.4.  IIUC, the "later version"
>>>> resolution will only happen if we stick with the same groupId.
>>>> Secondly, given the incompatibilities, the A part could blow up if
>>>> dbcp 1.4 is used (of course, Jorg's point is that A and B are
>>>> already incompatible in this case).
>>>
>>> I guess Niall has a point. However, look at this scenario with the example
>>> above:
>>>
>>> X is using Java 6
>>> A has been build using Java 1.4 (hence JDBC 3)
>>> B has been build using Java 6
>>>
>>> The question is now whether the app is broken or not. Can X using A
>>> successfully run on JDBC 4?
>>
>> Yes because nothing has been removed from JDBC 3 -> JDBC 4. Its no
>> different from X is using Commons IO 1.4 and A was built using Commons
>> IO 1.3 - can X using A successfully run with IO 1.4? As long as IO is
>> backwards compatible then theres no problem - same for JDBC. There
>> would have been screams by now if Apps built using JDBC 3 didn't work
>> when moving to JDK 1.6 (and therefore JDBC 4)
>>
>> Niall
>>
>>> - Jörg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Phil Steitz
In reply to this post by Niall Pemberton
Niall Pemberton wrote:

> 2009/11/27 Phil Steitz <[hidden email]>:
>> Niall Pemberton wrote:
>>> 2009/11/27 Phil Steitz <[hidden email]>:
>>>> Niall Pemberton wrote:
>>>>> On Fri, Nov 27, 2009 at 8:47 AM, Jörg Schaible <[hidden email]> 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.

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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Niall Pemberton
2009/11/28 Phil Steitz <[hidden email]>:

> Niall Pemberton wrote:
>> 2009/11/27 Phil Steitz <[hidden email]>:
>>> Niall Pemberton wrote:
>>>> 2009/11/27 Phil Steitz <[hidden email]>:
>>>>> Niall Pemberton wrote:
>>>>>> On Fri, Nov 27, 2009 at 8:47 AM, Jörg Schaible <[hidden email]> 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

> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

sebb-2-2
On 28/11/2009, Niall Pemberton <[hidden email]> wrote:

> 2009/11/28 Phil Steitz <[hidden email]>:
>
> > Niall Pemberton wrote:
>  >> 2009/11/27 Phil Steitz <[hidden email]>:
>  >>> Niall Pemberton wrote:
>  >>>> 2009/11/27 Phil Steitz <[hidden email]>:
>  >>>>> Niall Pemberton wrote:
>  >>>>>> On Fri, Nov 27, 2009 at 8:47 AM, Jörg Schaible <[hidden email]> 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: [hidden email]
>  For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Phil Steitz
In reply to this post by Niall Pemberton
Niall Pemberton wrote:

> 2009/11/28 Phil Steitz <[hidden email]>:
>> Niall Pemberton wrote:
>>> 2009/11/27 Phil Steitz <[hidden email]>:
>>>> Niall Pemberton wrote:
>>>>> 2009/11/27 Phil Steitz <[hidden email]>:
>>>>>> Niall Pemberton wrote:
>>>>>>> On Fri, Nov 27, 2009 at 8:47 AM, Jörg Schaible <[hidden email]> 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

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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Niall Pemberton
2009/11/28 Phil Steitz <[hidden email]>:

> Niall Pemberton wrote:
>> 2009/11/28 Phil Steitz <[hidden email]>:
>>> Niall Pemberton wrote:
>>>> 2009/11/27 Phil Steitz <[hidden email]>:
>>>>> Niall Pemberton wrote:
>>>>>> 2009/11/27 Phil Steitz <[hidden email]>:
>>>>>>> Niall Pemberton wrote:
>>>>>>>> On Fri, Nov 27, 2009 at 8:47 AM, Jörg Schaible <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Jörg Schaible
Niall Pemberton wrote:

> 2009/11/28 Phil Steitz <[hidden email]>:

[snip]

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

It's not enough to adjust the version in the POM, you have to adjust the SCM
URLs also to release with Maven from 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.

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Phil Steitz
Jörg Schaible wrote:

> Niall Pemberton wrote:
>
>> 2009/11/28 Phil Steitz <[hidden email]>:
>
> [snip]
>
>>> 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.
>
> It's not enough to adjust the version in the POM, you have to adjust the SCM
> URLs also to release with Maven from the branch.
>
Thanks for reminding me of this. I was not planning to use the
release plugin to perform the release, but I will adjust the scm URLs.

Phil

>>> 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.
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

1234