[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

Phil Steitz
Niall Pemberton wrote:

> On Thu, Nov 26, 2009 at 5:46 PM, Niall Pemberton
> <[hidden email]> wrote:
>> On Thu, Nov 26, 2009 at 4:57 PM, Phil Steitz <[hidden email]> wrote:
>>> Paul Benedict wrote:
>>>> Oops.. I meant minor version bumps ;-)
>>>>
>>>> On Thu, Nov 26, 2009 at 10:35 AM, Paul Benedict <[hidden email]> wrote:
>>>>> Another option to consider is splitting the version numbers such as:
>>>>>
>>>>> JDBC3 --> org.commons.apache.commons-dbcp-1.3.0
>>>>> JDBC4 --> org.commons.apache.commons-dbcp-1.4.0
>>>>>
>>>>> Unless you have expectations to continue supporting JDBC3 in the next
>>>>> major release, I would seriously suggest a version bump. The typical
>>>>> use case of major version bumps are incompatibilities.
>>>>>
>>>>> PS: You could also try splitting 1.3.0 / 1.3.5, but you would have to
>>>>> bring in a 4 digit for patch releases -- to avoid 5 1.3.0 patches
>>>>> incrementing to 1.3.5.
>>> Thanks, Paul.  That is an interesting idea.  Are you recommending
>>> that we change the groupId for both versions?  If not, we could end
>>> up with unintentional "latest version" upgrades causing problems.
>>> The numbering could also be a little misleading.
>>>
>>> What negatives do you see in
>>>
>>> org.apache.commons:dbcp:1.3
>>> commons-dbcp:commons-dbcp:1.3
>>>
>>> We have not decided yet on whether we will maintain jdbc 3 support
>>> in 2.0, though that is doubtful.
>>>
>>> One other thing to keep in mind is that there will almost certainly
>>> be 1.3.x patch releases to follow for both jdbc3 and jdbc4
>>>
>>> Phil
>>>>> Paul
>>>>>
>>>>> On Thu, Nov 26, 2009 at 10:12 AM, Phil Steitz <[hidden email]> wrote:
>>>>>> Jörg Schaible wrote:
>>>>>>> Hi Phil,
>>>>>>>
>>>>>>> Phil Steitz wrote at Donnerstag, 26. November 2009 15:20:
>>>>>>>
>>>>>>>> Jörg Schaible wrote:
>>>>>>> [snip]
>>>>>>>
>>>>>>>>> OK, but then we should really think about "drop-in replacement" or not.
>>>>>>>>> Basically we say that dbcp 1.3 with JDBC4 will not be backward
>>>>>>>>> compatible. Then why don't we use the new artifactId for this and allow
>>>>>>>>> 1.3 with JDBC3 to be a real drop-in replacement? If somebody works with
>>>>>>>>> ranges, he might get the newer dbcp anyway and wondering about the
>>>>>>>>> incompatibility later.
>>>>>>>>>
>>>>>>>>> Therefore we might better do:
>>>>>>>>>
>>>>>>>>> org.apache.commons:commons-dbcp4:1.3
>>>>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>>> Thanks Jorg and Grzegorz.  Really appreciate the feedback. It is
>>>>>>>> important that we get this right, minimizing confusion / bad impact
>>>>>>>> to maven users and making upgrades both safe and as easy as
>>>>>>>> possible. I was thinking the same way as you, Jörg, on the groupId
>>>>>>>> change for the jdbc4 version.
>>>>>>> Note, that I also changed the artifactId "dbcp vs. dbcp4" ;-)
>>>>>>>
>>>>>>> However, thinking about it, I am not sure if this is necessary and we can
>>>>>>> really keep the artifactId (your first plan). If somebody uses both
>>>>>>> artifacts (by transitive deps), his project is broken anyway. We simply have
>>>>>>> to point out in the website and README, that there are really two different
>>>>>>> commons-dbcp-1.3.jar files. Or is it too much confusion?
>>>>>> That worries ma a little bit, more for Ant than Maven users.
>>>>>> Incompatible jars with the same name in the wild is asking for
>>>>>> trouble (well, like the old days ;).
>>>>>>
>>>>>> Another option, given that we don't have to mess with relocation
>>>>>> poms, is just to use org.apache.commons:dbcp:1.3 for the jdbc4 version.
>> I'm starting to think it would be better to release two versions
>>  - DBCP 1.3 - compatible with JDBC3 and JDK 1.4
>>  - DBCP 1.4 - compatible with JDBC4 and JDK 1.6
>>
>> Use the same source, just change the version number, target JDK and
>> comment/uncomment the JDBC_4 markers.
>>
>> Wouldn't this be easier in the end? When you're ready to release DBCP
>> 1.4, then create a branch, run an ant task to comment the JDBC4 stuff,
>> change the version & JDK target.

You mean 1.3 above, right?
>
> P.S. I'm will to put the time in to do at least one of these releases
> - e.g. if you do DBCP 1.4, then I'll branch and create the equivalent
> DBCP 1.3 release

So I guess we're back to where I started ;)

Do we change the groupId for 1.4?  I am a little worried about
unintentional incompatible updates, otherwise.  Also, I assume we do
two release votes and two full distros, correct?

Thanks for the offer to help!

Phil




>
>> Niall
>>
>>
>>>>>> Phil
>>>>>>
>>>>>>
>>>>>>>> I see this as killing two birds with
>>>>>>>> one stone - getting us to the maven standard groupId moving forward
>>>>>>>> and eliminating or at least making less likely the chance of users
>>>>>>>> blowing up due to unintentional incompatible upgrades.
>>>>>>> Yes. And we can avoid the tedious relocation POMs, because it is no
>>>>>>> relocation.
>>>>>>>
>>>>>>>> Regarding Tomcat, Mark or someone else can chime in to confirm, but
>>>>>>>> my understanding is that tomcat builds and repackages dbcp from
>>>>>>>> source using Ant and as long as we keep trunk sources as they are,
>>>>>>>> tomcat will be able to build all versions.
>>>>>>> - 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]
>>>
>>>
>
> ---------------------------------------------------------------------
> 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

Paul Benedict
Phil, if you feel strongly about your concerns of incompatibility,
then I say keep the current groupId for 1.3, and move forward with
1.4/2.0 in the new groupId. This way people who continue to use the
old groupId will never get hit unexpectedly.

Paul

On Thu, Nov 26, 2009 at 11:55 AM, Phil Steitz <[hidden email]> wrote:

> Niall Pemberton wrote:
>> On Thu, Nov 26, 2009 at 5:46 PM, Niall Pemberton
>> <[hidden email]> wrote:
>>> On Thu, Nov 26, 2009 at 4:57 PM, Phil Steitz <[hidden email]> wrote:
>>>> Paul Benedict wrote:
>>>>> Oops.. I meant minor version bumps ;-)
>>>>>
>>>>> On Thu, Nov 26, 2009 at 10:35 AM, Paul Benedict <[hidden email]> wrote:
>>>>>> Another option to consider is splitting the version numbers such as:
>>>>>>
>>>>>> JDBC3 --> org.commons.apache.commons-dbcp-1.3.0
>>>>>> JDBC4 --> org.commons.apache.commons-dbcp-1.4.0
>>>>>>
>>>>>> Unless you have expectations to continue supporting JDBC3 in the next
>>>>>> major release, I would seriously suggest a version bump. The typical
>>>>>> use case of major version bumps are incompatibilities.
>>>>>>
>>>>>> PS: You could also try splitting 1.3.0 / 1.3.5, but you would have to
>>>>>> bring in a 4 digit for patch releases -- to avoid 5 1.3.0 patches
>>>>>> incrementing to 1.3.5.
>>>> Thanks, Paul.  That is an interesting idea.  Are you recommending
>>>> that we change the groupId for both versions?  If not, we could end
>>>> up with unintentional "latest version" upgrades causing problems.
>>>> The numbering could also be a little misleading.
>>>>
>>>> What negatives do you see in
>>>>
>>>> org.apache.commons:dbcp:1.3
>>>> commons-dbcp:commons-dbcp:1.3
>>>>
>>>> We have not decided yet on whether we will maintain jdbc 3 support
>>>> in 2.0, though that is doubtful.
>>>>
>>>> One other thing to keep in mind is that there will almost certainly
>>>> be 1.3.x patch releases to follow for both jdbc3 and jdbc4
>>>>
>>>> Phil
>>>>>> Paul
>>>>>>
>>>>>> On Thu, Nov 26, 2009 at 10:12 AM, Phil Steitz <[hidden email]> wrote:
>>>>>>> Jörg Schaible wrote:
>>>>>>>> Hi Phil,
>>>>>>>>
>>>>>>>> Phil Steitz wrote at Donnerstag, 26. November 2009 15:20:
>>>>>>>>
>>>>>>>>> Jörg Schaible wrote:
>>>>>>>> [snip]
>>>>>>>>
>>>>>>>>>> OK, but then we should really think about "drop-in replacement" or not.
>>>>>>>>>> Basically we say that dbcp 1.3 with JDBC4 will not be backward
>>>>>>>>>> compatible. Then why don't we use the new artifactId for this and allow
>>>>>>>>>> 1.3 with JDBC3 to be a real drop-in replacement? If somebody works with
>>>>>>>>>> ranges, he might get the newer dbcp anyway and wondering about the
>>>>>>>>>> incompatibility later.
>>>>>>>>>>
>>>>>>>>>> Therefore we might better do:
>>>>>>>>>>
>>>>>>>>>> org.apache.commons:commons-dbcp4:1.3
>>>>>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>>>> Thanks Jorg and Grzegorz.  Really appreciate the feedback. It is
>>>>>>>>> important that we get this right, minimizing confusion / bad impact
>>>>>>>>> to maven users and making upgrades both safe and as easy as
>>>>>>>>> possible. I was thinking the same way as you, Jörg, on the groupId
>>>>>>>>> change for the jdbc4 version.
>>>>>>>> Note, that I also changed the artifactId "dbcp vs. dbcp4" ;-)
>>>>>>>>
>>>>>>>> However, thinking about it, I am not sure if this is necessary and we can
>>>>>>>> really keep the artifactId (your first plan). If somebody uses both
>>>>>>>> artifacts (by transitive deps), his project is broken anyway. We simply have
>>>>>>>> to point out in the website and README, that there are really two different
>>>>>>>> commons-dbcp-1.3.jar files. Or is it too much confusion?
>>>>>>> That worries ma a little bit, more for Ant than Maven users.
>>>>>>> Incompatible jars with the same name in the wild is asking for
>>>>>>> trouble (well, like the old days ;).
>>>>>>>
>>>>>>> Another option, given that we don't have to mess with relocation
>>>>>>> poms, is just to use org.apache.commons:dbcp:1.3 for the jdbc4 version.
>>> I'm starting to think it would be better to release two versions
>>>  - DBCP 1.3 - compatible with JDBC3 and JDK 1.4
>>>  - DBCP 1.4 - compatible with JDBC4 and JDK 1.6
>>>
>>> Use the same source, just change the version number, target JDK and
>>> comment/uncomment the JDBC_4 markers.
>>>
>>> Wouldn't this be easier in the end? When you're ready to release DBCP
>>> 1.4, then create a branch, run an ant task to comment the JDBC4 stuff,
>>> change the version & JDK target.
>
> You mean 1.3 above, right?
>>
>> P.S. I'm will to put the time in to do at least one of these releases
>> - e.g. if you do DBCP 1.4, then I'll branch and create the equivalent
>> DBCP 1.3 release
>
> So I guess we're back to where I started ;)
>
> Do we change the groupId for 1.4?  I am a little worried about
> unintentional incompatible updates, otherwise.  Also, I assume we do
> two release votes and two full distros, correct?
>
> Thanks for the offer to help!
>
> Phil
>
>
>
>
>>
>>> Niall
>>>
>>>
>>>>>>> Phil
>>>>>>>
>>>>>>>
>>>>>>>>> I see this as killing two birds with
>>>>>>>>> one stone - getting us to the maven standard groupId moving forward
>>>>>>>>> and eliminating or at least making less likely the chance of users
>>>>>>>>> blowing up due to unintentional incompatible upgrades.
>>>>>>>> Yes. And we can avoid the tedious relocation POMs, because it is no
>>>>>>>> relocation.
>>>>>>>>
>>>>>>>>> Regarding Tomcat, Mark or someone else can chime in to confirm, but
>>>>>>>>> my understanding is that tomcat builds and repackages dbcp from
>>>>>>>>> source using Ant and as long as we keep trunk sources as they are,
>>>>>>>>> tomcat will be able to build all versions.
>>>>>>>> - 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]
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> 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

Jörg Schaible
In reply to this post by Paul Benedict
Hi Paul,

Paul Benedict wrote:

> Personally, I would not drop commons from the artiactId since it's a
> well-known prefix. Anyone who sees "commons" can reasonably guess it's
> from Apache Commons. Also let's not forget that in a file system,
> namespacing is still important. All file names still have to be unique
> in WEB-INF/lib :-)
>
> My first choice is this:
> org.apache.commons:commons-dbcp:1.4
> org.apache.commons:commons-dbcp:1.3

This is bead, since version 1.3 is not compatible to version 1.4 in this
case. Additionally you need then a relocation for 1.3.

> My second choice is this
> org.apache.commons:commons-dbcp:1.4
> commons-dbcp:commons-dbcp:1.3

This looks much better.
 
> PS: Since you have a 2.0 planned, perhaps you only want to change the
> groupId once you increment the major version?

Since the two versions will be incompatible, it is much better to change
groupId for the JDBC4 version now.

- 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
In reply to this post by Paul Benedict
Paul Benedict wrote:

> Phil, if you feel strongly about your concerns of incompatibility,
> then I say keep the current groupId for 1.3, and move forward with
> 1.4/2.0 in the new groupId. This way people who continue to use the
> old groupId will never get hit unexpectedly.

+1

- 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
In reply to this post by Paul Benedict
Paul Benedict wrote:

> I am +1 with Niall on two separate releases.

+1

Me too

- 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

Niall Pemberton
In reply to this post by Phil Steitz
On Thu, Nov 26, 2009 at 5:55 PM, Phil Steitz <[hidden email]> wrote:

> Niall Pemberton wrote:
>> On Thu, Nov 26, 2009 at 5:46 PM, Niall Pemberton
>> <[hidden email]> wrote:
>>> On Thu, Nov 26, 2009 at 4:57 PM, Phil Steitz <[hidden email]> wrote:
>>>> Paul Benedict wrote:
>>>>> Oops.. I meant minor version bumps ;-)
>>>>>
>>>>> On Thu, Nov 26, 2009 at 10:35 AM, Paul Benedict <[hidden email]> wrote:
>>>>>> Another option to consider is splitting the version numbers such as:
>>>>>>
>>>>>> JDBC3 --> org.commons.apache.commons-dbcp-1.3.0
>>>>>> JDBC4 --> org.commons.apache.commons-dbcp-1.4.0
>>>>>>
>>>>>> Unless you have expectations to continue supporting JDBC3 in the next
>>>>>> major release, I would seriously suggest a version bump. The typical
>>>>>> use case of major version bumps are incompatibilities.
>>>>>>
>>>>>> PS: You could also try splitting 1.3.0 / 1.3.5, but you would have to
>>>>>> bring in a 4 digit for patch releases -- to avoid 5 1.3.0 patches
>>>>>> incrementing to 1.3.5.
>>>> Thanks, Paul.  That is an interesting idea.  Are you recommending
>>>> that we change the groupId for both versions?  If not, we could end
>>>> up with unintentional "latest version" upgrades causing problems.
>>>> The numbering could also be a little misleading.
>>>>
>>>> What negatives do you see in
>>>>
>>>> org.apache.commons:dbcp:1.3
>>>> commons-dbcp:commons-dbcp:1.3
>>>>
>>>> We have not decided yet on whether we will maintain jdbc 3 support
>>>> in 2.0, though that is doubtful.
>>>>
>>>> One other thing to keep in mind is that there will almost certainly
>>>> be 1.3.x patch releases to follow for both jdbc3 and jdbc4
>>>>
>>>> Phil
>>>>>> Paul
>>>>>>
>>>>>> On Thu, Nov 26, 2009 at 10:12 AM, Phil Steitz <[hidden email]> wrote:
>>>>>>> Jörg Schaible wrote:
>>>>>>>> Hi Phil,
>>>>>>>>
>>>>>>>> Phil Steitz wrote at Donnerstag, 26. November 2009 15:20:
>>>>>>>>
>>>>>>>>> Jörg Schaible wrote:
>>>>>>>> [snip]
>>>>>>>>
>>>>>>>>>> OK, but then we should really think about "drop-in replacement" or not.
>>>>>>>>>> Basically we say that dbcp 1.3 with JDBC4 will not be backward
>>>>>>>>>> compatible. Then why don't we use the new artifactId for this and allow
>>>>>>>>>> 1.3 with JDBC3 to be a real drop-in replacement? If somebody works with
>>>>>>>>>> ranges, he might get the newer dbcp anyway and wondering about the
>>>>>>>>>> incompatibility later.
>>>>>>>>>>
>>>>>>>>>> Therefore we might better do:
>>>>>>>>>>
>>>>>>>>>> org.apache.commons:commons-dbcp4:1.3
>>>>>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>>>> Thanks Jorg and Grzegorz.  Really appreciate the feedback. It is
>>>>>>>>> important that we get this right, minimizing confusion / bad impact
>>>>>>>>> to maven users and making upgrades both safe and as easy as
>>>>>>>>> possible. I was thinking the same way as you, Jörg, on the groupId
>>>>>>>>> change for the jdbc4 version.
>>>>>>>> Note, that I also changed the artifactId "dbcp vs. dbcp4" ;-)
>>>>>>>>
>>>>>>>> However, thinking about it, I am not sure if this is necessary and we can
>>>>>>>> really keep the artifactId (your first plan). If somebody uses both
>>>>>>>> artifacts (by transitive deps), his project is broken anyway. We simply have
>>>>>>>> to point out in the website and README, that there are really two different
>>>>>>>> commons-dbcp-1.3.jar files. Or is it too much confusion?
>>>>>>> That worries ma a little bit, more for Ant than Maven users.
>>>>>>> Incompatible jars with the same name in the wild is asking for
>>>>>>> trouble (well, like the old days ;).
>>>>>>>
>>>>>>> Another option, given that we don't have to mess with relocation
>>>>>>> poms, is just to use org.apache.commons:dbcp:1.3 for the jdbc4 version.
>>> I'm starting to think it would be better to release two versions
>>>  - DBCP 1.3 - compatible with JDBC3 and JDK 1.4
>>>  - DBCP 1.4 - compatible with JDBC4 and JDK 1.6
>>>
>>> Use the same source, just change the version number, target JDK and
>>> comment/uncomment the JDBC_4 markers.
>>>
>>> Wouldn't this be easier in the end? When you're ready to release DBCP
>>> 1.4, then create a branch, run an ant task to comment the JDBC4 stuff,
>>> change the version & JDK target.
>
> You mean 1.3 above, right?

Yes sorry - I gave this a quick try here:

http://svn.apache.org/viewvc/commons/proper/dbcp/branches/TEST_DBCP_1_3_BRANCH/

Would need to do a bit more for a proper release - version no, release
notes, site etc

>> P.S. I'm will to put the time in to do at least one of these releases
>> - e.g. if you do DBCP 1.4, then I'll branch and create the equivalent
>> DBCP 1.3 release
>
> So I guess we're back to where I started ;)

Sorry :( - I'm just throwing out ideas, but feel free to ignore if you want

> Do we change the groupId for 1.4?  I am a little worried about
> unintentional incompatible updates, otherwise.

I think were OK compatibility wise - DBCP will have additional methods
and require JDK 1.6 - but I generated a 1.3-SNAPSHOT from that branch
and then did a 1.4-SNAPSHOT from trunk and the clirr reports look OK
in the 1.4 version

clirr reports:
http://people.apache.org/~niallp/dbcp13/site/clirr-report.html
http://people.apache.org/~niallp/dbcp14/site/clirr-report.html

>  Also, I assume we do
> two release votes and two full distros, correct?

Yes I think so. Just get the 1.4 version into a state where we thinks
its ready to release then Tag DBCP 1.4 from trunk. The create a DBCP
1.3 Branch from the DBCP 1.4 tag and run the ant script to comment out
the JDBC 4 methods + updates for 1.3 version. Then tag DBCP 1.3. Then
we do the usual release stuff for both 1.3 and 1.4 versions.

distros:
http://people.apache.org/~niallp/dbcp13/
http://people.apache.org/~niallp/dbcp14/


> Thanks for the offer to help!

np

Niall

> Phil
>
>
>
>
>>
>>> Niall
>>>
>>>
>>>>>>> Phil
>>>>>>>
>>>>>>>
>>>>>>>>> I see this as killing two birds with
>>>>>>>>> one stone - getting us to the maven standard groupId moving forward
>>>>>>>>> and eliminating or at least making less likely the chance of users
>>>>>>>>> blowing up due to unintentional incompatible upgrades.
>>>>>>>> Yes. And we can avoid the tedious relocation POMs, because it is no
>>>>>>>> relocation.
>>>>>>>>
>>>>>>>>> Regarding Tomcat, Mark or someone else can chime in to confirm, but
>>>>>>>>> my understanding is that tomcat builds and repackages dbcp from
>>>>>>>>> source using Ant and as long as we keep trunk sources as they are,
>>>>>>>>> tomcat will be able to build all versions.
>>>>>>>> - 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]
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> 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

Grzegorz S?owikowski
In reply to this post by Phil Steitz


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

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.

IMHO the safest and most conservative naming convention would be:

commons-dbcp:commons-dbcp:1.4
commons-dbcp:commons-dbcp:1.3

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.

Greetings

Grzegorz Slowikowski

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

Jörg Schaible
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.

> 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

Grzegorz S?owikowski
Hi Jorg

Jörg Schaible 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.
>
>
>  
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.
I narrow differency definition to artifactId only because after you
prepare your distribution
(as zip or war file for example) your users don't see groupids of
contained artifacts.
This comes from my practice, not Maven documentations.

>> 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.
>
>  
If you decide to branch your codebase and separate the release processes
of trunk and branch versions
(1.4 and 1.3) then tis is THE SAME artifact for me. The 1.4 version is
not backward compatible,
but this does not change the fact that this is the same artifact (the
same functionality, the same classes
in the same packages). Don't let Maven (or any other build tool) to
treat them separately and potentially
place both in the classpath.
The situation where both jars will be in the classpath is the case I'm
aware most!!! It's not important
who (Maven, Ant, ?) is responsible for that.

>> 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.
>  
You are right. I forget about varsions in file names.

>  
>> 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
>  
The same as above.

>  
>> 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.
>  
OK, but it would be good to know what problems may occur if we user
relocation
from commons:commons:commons-dbcp:1.4 to
org.apache.commons:commons-dbcp4:1.4.
I saw such proposals somewhere in this thread.

>  
>  
>> 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.
>  
After a lot of thinking about it, it IS an upgrade for me. If you
upgrade Java to 1.6, you can upgrade
commons-jdbc. If you don't want to upgrade, you can always specify a
version (in your pom or whereever)
you want.
I know you see it differently, but I disagree with you. Sorry.

>  
>> 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.
>  
I'm talking about developers who don't know Maven well, don't know
comons-dbcp version naming
conventions well too, and who will make a lot of errors, wrong
assumptions, and will ask a lot of questions
why something does not work.
This is again from my practice. Everything must be deadly simple.
I don't know commons-dbcp project internals, I'm only using it in my
projects (testing with Spring) and in Tomcat
(production). I think I can see things differently from you - developers
of commons-dbcp project.

Greetings

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

Jörg Schaible
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 narrow differency definition to artifactId only because after you
> prepare your distribution
> (as zip or war file for example) your users don't see groupids of
> contained artifacts.
> This comes from my practice, not Maven documentations.

The example above *is* the practice and is not Maven specific.

[snip]

> If you decide to branch your codebase and separate the release processes
> of trunk and branch versions
> (1.4 and 1.3) then tis is THE SAME artifact for me. The 1.4 version is
> not backward compatible,
> but this does not change the fact that this is the same artifact (the
> same functionality, the same classes
> in the same packages). Don't let Maven (or any other build tool) to
> treat them separately and potentially
> place both in the classpath.

As explained - it does not matter for the resulting app - it is broken,
because it tries to use JDBC3 and JDBC4 at the same time.

> The situation where both jars will be in the classpath is the case I'm
> aware most!!! It's not important
> who (Maven, Ant, ?) is responsible for that.

If you have both jars in the shared folder you get at least a hint, that
something's wrong with your application. The current proposal with:

org.apache.commons:commons-dbcp:1.4
commons-dbcp:commons-dbcp:1.3

will have the effect (at least for Maven builds) that you end up with
commons-dbcp-1.3.jar and commons-dbcp-1.4.jar in your classpath and you
should realize that this is a no-no.

As said, the tool can not resolve the causing problem itself - all it can do
is give you a hint. Using a tool is no excuse from thinking yourself. And
two jars with same name (except version) is IMHO a better hint, that having
simply one without recognizing that A or B is implicitly broken and failing
your app.

[snip]

>>> 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.
>>  
> You are right. I forget about varsions in file names.

And - as explained - the groupId will be prepended to the name if
{artifactId}-{version} is not unique.

[snip]

>> No relocations involved here.
>>  
> OK, but it would be good to know what problems may occur if we user
> relocation
> from commons:commons:commons-dbcp:1.4 to
> org.apache.commons:commons-dbcp4:1.4.
> I saw such proposals somewhere in this thread.

Relocation will make it worse, since then you will tell Maven that it is the
same artifact in different version - which it is not.

>>> 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.
>>  
> After a lot of thinking about it, it IS an upgrade for me. If you
> upgrade Java to 1.6, you can upgrade
> commons-jdbc. If you don't want to upgrade, you can always specify a
> version (in your pom or whereever)
> you want.
> I know you see it differently, but I disagree with you. Sorry.

Yes, it is an upgrade, but you have to deal with more than just dbcp and a
user should realize that his upgrade from JDBC3 to JDBC4 is something that
is not backward compatible and has to be supported by all (transitive) deps.

[snip]

> I'm talking about developers who don't know Maven well, don't know
> comons-dbcp version naming
> conventions well too, and who will make a lot of errors, wrong
> assumptions, and will ask a lot of questions
> why something does not work.
> This is again from my practice. Everything must be deadly simple.
> I don't know commons-dbcp project internals, I'm only using it in my
> projects (testing with Spring) and in Tomcat
> (production). I think I can see things differently from you - developers
> of commons-dbcp project.

Actually we have to deal with a situation, where every move will cause a
problem for someone. A developer must be aware that switching from Java 5 to
Jave 6 also means an (incompatible) upgrade from JDBC 3 to JDBC 4 - at least
if he uses JDBC. Either he knows or he must learn - I do not see a way out,
unfortunately. And this is completely unrelated with the build tool.

- 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

Niall Pemberton
In reply to this post by Jörg Schaible
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?

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
In reply to this post by Jörg Schaible
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.

Niall

>> I narrow differency definition to artifactId only because after you
>> prepare your distribution
>> (as zip or war file for example) your users don't see groupids of
>> contained artifacts.
>> This comes from my practice, not Maven documentations.
>
> The example above *is* the practice and is not Maven specific.
>
> [snip]
>
>> If you decide to branch your codebase and separate the release processes
>> of trunk and branch versions
>> (1.4 and 1.3) then tis is THE SAME artifact for me. The 1.4 version is
>> not backward compatible,
>> but this does not change the fact that this is the same artifact (the
>> same functionality, the same classes
>> in the same packages). Don't let Maven (or any other build tool) to
>> treat them separately and potentially
>> place both in the classpath.
>
> As explained - it does not matter for the resulting app - it is broken,
> because it tries to use JDBC3 and JDBC4 at the same time.
>
>> The situation where both jars will be in the classpath is the case I'm
>> aware most!!! It's not important
>> who (Maven, Ant, ?) is responsible for that.
>
> If you have both jars in the shared folder you get at least a hint, that
> something's wrong with your application. The current proposal with:
>
> org.apache.commons:commons-dbcp:1.4
> commons-dbcp:commons-dbcp:1.3
>
> will have the effect (at least for Maven builds) that you end up with
> commons-dbcp-1.3.jar and commons-dbcp-1.4.jar in your classpath and you
> should realize that this is a no-no.
>
> As said, the tool can not resolve the causing problem itself - all it can do
> is give you a hint. Using a tool is no excuse from thinking yourself. And
> two jars with same name (except version) is IMHO a better hint, that having
> simply one without recognizing that A or B is implicitly broken and failing
> your app.
>
> [snip]
>
>>>> 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.
>>>
>> You are right. I forget about varsions in file names.
>
> And - as explained - the groupId will be prepended to the name if
> {artifactId}-{version} is not unique.
>
> [snip]
>
>>> No relocations involved here.
>>>
>> OK, but it would be good to know what problems may occur if we user
>> relocation
>> from commons:commons:commons-dbcp:1.4 to
>> org.apache.commons:commons-dbcp4:1.4.
>> I saw such proposals somewhere in this thread.
>
> Relocation will make it worse, since then you will tell Maven that it is the
> same artifact in different version - which it is not.
>
>>>> 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.
>>>
>> After a lot of thinking about it, it IS an upgrade for me. If you
>> upgrade Java to 1.6, you can upgrade
>> commons-jdbc. If you don't want to upgrade, you can always specify a
>> version (in your pom or whereever)
>> you want.
>> I know you see it differently, but I disagree with you. Sorry.
>
> Yes, it is an upgrade, but you have to deal with more than just dbcp and a
> user should realize that his upgrade from JDBC3 to JDBC4 is something that
> is not backward compatible and has to be supported by all (transitive) deps.
>
> [snip]
>
>> I'm talking about developers who don't know Maven well, don't know
>> comons-dbcp version naming
>> conventions well too, and who will make a lot of errors, wrong
>> assumptions, and will ask a lot of questions
>> why something does not work.
>> This is again from my practice. Everything must be deadly simple.
>> I don't know commons-dbcp project internals, I'm only using it in my
>> projects (testing with Spring) and in Tomcat
>> (production). I think I can see things differently from you - developers
>> of commons-dbcp project.
>
> Actually we have to deal with a situation, where every move will cause a
> problem for someone. A developer must be aware that switching from Java 5 to
> Jave 6 also means an (incompatible) upgrade from JDBC 3 to JDBC 4 - at least
> if he uses JDBC. Either he knows or he must learn - I do not see a way out,
> unfortunately. And this is completely unrelated with the build tool.
>
> - 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
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).

Phil


>
> Niall
>
>>> I narrow differency definition to artifactId only because after you
>>> prepare your distribution
>>> (as zip or war file for example) your users don't see groupids of
>>> contained artifacts.
>>> This comes from my practice, not Maven documentations.
>> The example above *is* the practice and is not Maven specific.
>>
>> [snip]
>>
>>> If you decide to branch your codebase and separate the release processes
>>> of trunk and branch versions
>>> (1.4 and 1.3) then tis is THE SAME artifact for me. The 1.4 version is
>>> not backward compatible,
>>> but this does not change the fact that this is the same artifact (the
>>> same functionality, the same classes
>>> in the same packages). Don't let Maven (or any other build tool) to
>>> treat them separately and potentially
>>> place both in the classpath.
>> As explained - it does not matter for the resulting app - it is broken,
>> because it tries to use JDBC3 and JDBC4 at the same time.
>>
>>> The situation where both jars will be in the classpath is the case I'm
>>> aware most!!! It's not important
>>> who (Maven, Ant, ?) is responsible for that.
>> If you have both jars in the shared folder you get at least a hint, that
>> something's wrong with your application. The current proposal with:
>>
>> org.apache.commons:commons-dbcp:1.4
>> commons-dbcp:commons-dbcp:1.3
>>
>> will have the effect (at least for Maven builds) that you end up with
>> commons-dbcp-1.3.jar and commons-dbcp-1.4.jar in your classpath and you
>> should realize that this is a no-no.
>>
>> As said, the tool can not resolve the causing problem itself - all it can do
>> is give you a hint. Using a tool is no excuse from thinking yourself. And
>> two jars with same name (except version) is IMHO a better hint, that having
>> simply one without recognizing that A or B is implicitly broken and failing
>> your app.
>>
>> [snip]
>>
>>>>> 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.
>>>>
>>> You are right. I forget about varsions in file names.
>> And - as explained - the groupId will be prepended to the name if
>> {artifactId}-{version} is not unique.
>>
>> [snip]
>>
>>>> No relocations involved here.
>>>>
>>> OK, but it would be good to know what problems may occur if we user
>>> relocation
>>> from commons:commons:commons-dbcp:1.4 to
>>> org.apache.commons:commons-dbcp4:1.4.
>>> I saw such proposals somewhere in this thread.
>> Relocation will make it worse, since then you will tell Maven that it is the
>> same artifact in different version - which it is not.
>>
>>>>> 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.
>>>>
>>> After a lot of thinking about it, it IS an upgrade for me. If you
>>> upgrade Java to 1.6, you can upgrade
>>> commons-jdbc. If you don't want to upgrade, you can always specify a
>>> version (in your pom or whereever)
>>> you want.
>>> I know you see it differently, but I disagree with you. Sorry.
>> Yes, it is an upgrade, but you have to deal with more than just dbcp and a
>> user should realize that his upgrade from JDBC3 to JDBC4 is something that
>> is not backward compatible and has to be supported by all (transitive) deps.
>>
>> [snip]
>>
>>> I'm talking about developers who don't know Maven well, don't know
>>> comons-dbcp version naming
>>> conventions well too, and who will make a lot of errors, wrong
>>> assumptions, and will ask a lot of questions
>>> why something does not work.
>>> This is again from my practice. Everything must be deadly simple.
>>> I don't know commons-dbcp project internals, I'm only using it in my
>>> projects (testing with Spring) and in Tomcat
>>> (production). I think I can see things differently from you - developers
>>> of commons-dbcp project.
>> Actually we have to deal with a situation, where every move will cause a
>> problem for someone. A developer must be aware that switching from Java 5 to
>> Jave 6 also means an (incompatible) upgrade from JDBC 3 to JDBC 4 - at least
>> if he uses JDBC. Either he knows or he must learn - I do not see a way out,
>> unfortunately. And this is completely unrelated with the build tool.
>>
>> - 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:

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

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

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

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

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

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

Jörg Schaible
In reply to this post by Phil Steitz
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?

- 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

Niall Pemberton
In reply to this post by Phil Steitz
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.

Niall

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

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Niall Pemberton
In reply to this post by Jörg Schaible
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]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

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

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]

1234