[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

Jörg Schaible
Hi Paul,

Paul Benedict wrote at Donnerstag, 26. November 2009 05:03:

> When I was patching Hibernate, they needed different sources because
> of JDBC3/4 incompatibility. It just wasn't possible to compile for
> both dependencies.
>
> I just checked with Brett Porter of Maven. He says that if the sources
> are identical, you can use qualifiers; otherwise it would conflict
> when you generate sources/javadocs/tests. You couldn't publish
> different sources/etc. once the qualifier is used -- makes sense you
> can't append more than one qualifier.
>
> Based on this advice, I revert to my previous advice and say they
> should be separate artifactIds with no qualifiers.

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

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


Phil Steitz wrote:

> Paul Benedict wrote:
>  
>> When I was patching Hibernate, they needed different sources because
>> of JDBC3/4 incompatibility. It just wasn't possible to compile for
>> both dependencies.
>>
>> I just checked with Brett Porter of Maven. He says that if the sources
>> are identical, you can use qualifiers; otherwise it would conflict
>> when you generate sources/javadocs/tests. You couldn't publish
>> different sources/etc. once the qualifier is used -- makes sense you
>> can't append more than one qualifier.
>>
>> Based on this advice, I revert to my previous advice and say they
>> should be separate artifactIds with no qualifiers.
>>    
>
> I was planning to use Ant to generate the jdbc3 release jar anyway,
> since the Ant build has the filtering set up and I am not dying to
> wrestle maven into doing this.  So here is a slightly kludgy
> solution that IIUC would be maven-tolerable:
>
> 1. Run the Ant build under 1.5 to filter the sources into /build/src
> 2. Copy the pom to /build
> 3. cd /build and execute mvn source:jar mvn javadoc:jar mvn package
> there (from the filtered sources)
> 4. cd back to basedir and execute the release build using the pom
> modified to attach the artifacts in /build with jdbc3 classifiers
> (as in subetha example, though using two levels in the classifiers
> for the sources and javadoc jars - jdbc3-sources, jdbc3-javadoc)
>
>  
If you want to go it this way, then "jdbc3" is not a classifier, it is a
name suffix.
> This seems to work. If there are no objections, I will cut an RC
> between veggie turkey bites tomorrow using this approach.
>
> Phil
>
>  
Hi

I want to add something from myself, I think I'm experienced Maven user.

1. As Paul said, when you have two different sources you should not try
to use classifiers
(I think technically it could be possible, but it is wrong way). There
are projects generating
two artifacts: base one and  jdk 1.4 compatible one. As i know, the
second one is generated from
the same classes as the first one using retrotranslator or retroweaver
plugin in the build process.
Subethasmtp is a good example:
http://repo2.maven.org/maven2/org/subethamail/subethasmtp-smtp/1.2/subethasmtp-smtp-1.2.pom

2. I agree with Jorg that the JDBC3 version should be the natural
continuation of previous
versions, so commons-dbcp:commons-dbcp:1.3 would be for JDBC3, not JDBC4.
I know that Tomcat developers are waiting for new version of
commons-dbcp because of some leaks
in current commons-pool version (if I remember). Tomcat6 has Java5 as a
minimum. I thing, they
will not use jdbc4 version of commons-dbcp. If jdbc3 compatible version
will have different name
("-jdbc3" suffix) you will have to answer millions of questions about it.

3. The build process described here by Paul should work, but I don't
like the Maven+Ant hybrid.
Tomcat developers (again) will have problems, because they are
generating their "tomcat-dbcp.jar"
from commons-pool and commons-dbcp sources. They download these two
sources bundle,
change package names and merge them into one archive. If commons-dbcp
sources will be
jdbc4 compatible, they will have to repeat your 1. step above.
I wonder if it is possible to split commons-dbcp code base into two
modules and build them
entirely in Maven. I made some simple tests. I could upload it somewhere
for you.

Sorry for my English

Greetings

Grzegorz Slowikowski

>> Paul
>>
>> On Wed, Nov 25, 2009 at 6:51 PM, Niall Pemberton
>> <[hidden email]> wrote:
>>    
>>> On Thu, Nov 26, 2009 at 12:46 AM, Paul Benedict <[hidden email]> wrote:
>>>      
>>>> Does adding a classifier like "jdbc3" affect the creation of the
>>>> -source and -javadoc classifiers?
>>>>        
>>> I don't believe it should - those are produced by the sources and
>>> javadoc plugins respectively. In the commons build those plugins are
>>> configured to produce the source/javadoc jars only in the "rc" profile
>>> - so running mvn -Prc package should see them produced.
>>>
>>> Niall
>>>
>>>      
>>>> On Wed, Nov 25, 2009 at 6:06 PM, Phil Steitz <[hidden email]> wrote:
>>>>        
>>>>> Niall Pemberton wrote:
>>>>>          
>>>>>> On Wed, Nov 25, 2009 at 11:39 PM, Niall Pemberton
>>>>>> <[hidden email]> wrote:
>>>>>>            
>>>>>>> On Wed, Nov 25, 2009 at 11:31 PM, Phil Steitz <[hidden email]> wrote:
>>>>>>>              
>>>>>>>> Niall Pemberton wrote:
>>>>>>>>                
>>>>>>>>> On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict <[hidden email]> wrote:
>>>>>>>>>                  
>>>>>>>>>> Phil,
>>>>>>>>>>
>>>>>>>>>> I don't think you should be modifying the version (and groups, really)
>>>>>>>>>> here. All the artifacts belong to version 1.3.
>>>>>>>>>>
>>>>>>>>>> Maven does have a concept of a qualifier, but according to Sonatype,
>>>>>>>>>> it's only to capture milestone builds:
>>>>>>>>>> http://www.sonatype.com/books/maven-book/reference/pom-relationships-sect-pom-syntax.html
>>>>>>>>>>                    
>>>>>>>>> I don't think this is true maven has used "classifier" to distribute
>>>>>>>>> various artifacts that are attached to the project - such as
>>>>>>>>> "sources", "javadocs", test jar and it talks about them here in the
>>>>>>>>> same book
>>>>>>>>>
>>>>>>>>> http://www.sonatype.com/books/maven-book/reference/assemblies-sect-output-algorithm.html#assemblies-sect-transitive
>>>>>>>>>
>>>>>>>>> Also its been a fairly common pratice with many projects using a maven
>>>>>>>>> build to provide JDK 1.4 compatible jars after the project moved to
>>>>>>>>> JDK 1.5 using some kind of classifier - this is pretty much the same
>>>>>>>>> situation.
>>>>>>>>>
>>>>>>>>> If you use a different artifactId for the different jars then its
>>>>>>>>> going to be a bigger PITA for the release - since you'll need a pom
>>>>>>>>> and have to update maven-metadata.xml - probably anually. This is what
>>>>>>>>> happened in BeanUtils and doing a release is much more painful and
>>>>>>>>> prone to errors.
>>>>>>>>>                  
>>>>>>>> Stupid question.  Assuming we go the classifier route, how can I use
>>>>>>>> just one pom?  I was assuming I would have to hack a second pom in
>>>>>>>> either case.
>>>>>>>>                
>>>>>>> AFAIK you don't have to do anything - just produce the additional jars
>>>>>>> with the classifier in the name - its people who consume it who
>>>>>>> specifiy the classifier - for example say you produce an additional
>>>>>>> jar called commons-dbcp-1.3-jdbc3.jar then if someone wanted to use
>>>>>>> that rather than the standard commons-dbcp-1.3.jar then they would
>>>>>>> specify the dependency as follows:
>>>>>>>
>>>>>>>    <dependency>
>>>>>>>      <groupId>commons-dbcp</groupId>
>>>>>>>      <artifactId>commons-dbcp</artifactId>
>>>>>>>      <version>1.3</version>
>>>>>>>      <classifier>jdbc3</classifier>
>>>>>>>    </dependency>
>>>>>>>
>>>>>>> Haven't read it, but also found this:
>>>>>>>
>>>>>>> http://www.sonatype.com/books/maven-book/reference/profiles-sect-platform-classifier.html
>>>>>>>              
>>>>>> Found an example subethasmtp-smtp has a JDK 1.4 jar:
>>>>>>
>>>>>> http://repo2.maven.org/maven2/org/subethamail/subethasmtp-smtp/1.2/
>>>>>>
>>>>>> And  Commons Email 1.2 depends on the JDK 1.4 jar:
>>>>>>
>>>>>> http://repo2.maven.org/maven2/org/apache/commons/commons-email/1.2/commons-email-1.2.pom
>>>>>>            
>>>>> Thanks, Niall!
>>>>>          
>>>>>> Niall
>>>>>>
>>>>>>            
>>>>>>> Niall
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>> Phil
>>>>>>>>                
>>>>>>>>> I would go down the classifer route.
>>>>>>>>>
>>>>>>>>> Niall
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>> What you have, simply, is, different artifacts. Keep the same groupId
>>>>>>>>>> and version, just alter the artifact names.
>>>>>>>>>>
>>>>>>>>>> JDBC 4 version (JDK 1.6)
>>>>>>>>>> groupId = org.apache.commons
>>>>>>>>>> artifactId = commons-dbcp
>>>>>>>>>> version = 1.3
>>>>>>>>>>
>>>>>>>>>> JDBC 3 version (JDK 1.4-1.5)
>>>>>>>>>> groupId = org.apache.commons
>>>>>>>>>> artifactId = commons-dbcp-jdbc3
>>>>>>>>>> version = 1.3
>>>>>>>>>>
>>>>>>>>>> Paul
>>>>>>>>>>
>>>>>>>>>> On Wed, Nov 25, 2009 at 4:14 PM, Phil Steitz <[hidden email]> wrote:
>>>>>>>>>>                    
>>>>>>>>>>> Phil Steitz wrote:
>>>>>>>>>>>                      
>>>>>>>>>>>> I am about to roll an RC and I need to make sure all are OK with the
>>>>>>>>>>>>  artifact names and repo placement
>>>>>>>>>>>>
>>>>>>>>>>>> JDBC 4 version (JDK 1.6)
>>>>>>>>>>>> groupId org.apache.maven
>>>>>>>>>>>>                        
>>>>>>>>>>> Oops! I obviously mean commons above :)
>>>>>>>>>>>                      
>>>>>>>>>>>> artifactID commons-dbcp
>>>>>>>>>>>> version 1.3
>>>>>>>>>>>>
>>>>>>>>>>>> JDBC 3 version (JDK 1.4-1.5)
>>>>>>>>>>>> groupId commons-dbcp
>>>>>>>>>>>> artifactId commons-dbcp
>>>>>>>>>>>> version 1.3-jdbc3
>>>>>>>>>>>>
>>>>>>>>>>>> Giving the 1.3 name to the 1.6 version makes sense as this is the
>>>>>>>>>>>> main development version.  Moving it gets it into compliance with
>>>>>>>>>>>> the maven standard and avoids unintended consequences of upgrading
>>>>>>>>>>>> for 1.4-1.5 users by requiring a bigger change.
>>>>>>>>>>>>
>>>>>>>>>>>> Alternatively, we could put descriptors on both and leave placement
>>>>>>>>>>>> as is. Opinions please.
>>>>>>>>>>>>
>>>>>>>>>>>> Phil
>>>>>>>>>>>>                        
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> 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]
>>>>
>>>>
>>>>        
>>> ---------------------------------------------------------------------
>>> 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
Hi Grzegorz,

Grzegorz Słowikowski wrote at Donnerstag, 26. November 2009 10:59:

[snip]

> Hi
>
> I want to add something from myself, I think I'm experienced Maven user.
>
> 1. As Paul said, when you have two different sources you should not try
> to use classifiers
> (I think technically it could be possible, but it is wrong way). There
> are projects generating
> two artifacts: base one and  jdk 1.4 compatible one. As i know, the
> second one is generated from
> the same classes as the first one using retrotranslator or retroweaver
> plugin in the build process.
> Subethasmtp is a good example:
> http://repo2.maven.org/maven2/org/subethamail/subethasmtp-
smtp/1.2/subethasmtp-smtp-1.2.pom

>
> 2. I agree with Jorg that the JDBC3 version should be the natural
> continuation of previous
> versions, so commons-dbcp:commons-dbcp:1.3 would be for JDBC3, not JDBC4.
> I know that Tomcat developers are waiting for new version of
> commons-dbcp because of some leaks
> in current commons-pool version (if I remember). Tomcat6 has Java5 as a
> minimum. I thing, they
> will not use jdbc4 version of commons-dbcp. If jdbc3 compatible version
> will have different name
> ("-jdbc3" suffix) you will have to answer millions of questions about it.
>
> 3. The build process described here by Paul should work, but I don't
> like the Maven+Ant hybrid.
> Tomcat developers (again) will have problems, because they are
> generating their "tomcat-dbcp.jar"
> from commons-pool and commons-dbcp sources. They download these two
> sources bundle,
> change package names and merge them into one archive. If commons-dbcp
> sources will be
> jdbc4 compatible, they will have to repeat your 1. step above.
> I wonder if it is possible to split commons-dbcp code base into two
> modules and build them
> entirely in Maven.

You will always have an Ant task to perform the source generation of the
"conditional" compilation. The trunk builds only with JDBC4, the Ant task
has to run before building against JDBC3.

> I made some simple tests. I could upload it somewhere
> for you.

You might use the -source artifact as dependency in the second module and
unpack it with the dependency plugin and use then the Ant task to prepare
the sources.

- 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


Jörg Schaible wrote:

> Hi Grzegorz,
>
> Grzegorz Słowikowski wrote at Donnerstag, 26. November 2009 10:59:
>
> [snip]
>
>  
>> Hi
>>
>> I want to add something from myself, I think I'm experienced Maven user.
>>
>> 1. As Paul said, when you have two different sources you should not try
>> to use classifiers
>> (I think technically it could be possible, but it is wrong way). There
>> are projects generating
>> two artifacts: base one and  jdk 1.4 compatible one. As i know, the
>> second one is generated from
>> the same classes as the first one using retrotranslator or retroweaver
>> plugin in the build process.
>> Subethasmtp is a good example:
>> http://repo2.maven.org/maven2/org/subethamail/subethasmtp-
>>    
> smtp/1.2/subethasmtp-smtp-1.2.pom
>  
>> 2. I agree with Jorg that the JDBC3 version should be the natural
>> continuation of previous
>> versions, so commons-dbcp:commons-dbcp:1.3 would be for JDBC3, not JDBC4.
>> I know that Tomcat developers are waiting for new version of
>> commons-dbcp because of some leaks
>> in current commons-pool version (if I remember). Tomcat6 has Java5 as a
>> minimum. I thing, they
>> will not use jdbc4 version of commons-dbcp. If jdbc3 compatible version
>> will have different name
>> ("-jdbc3" suffix) you will have to answer millions of questions about it.
>>
>> 3. The build process described here by Paul should work, but I don't
>> like the Maven+Ant hybrid.
>> Tomcat developers (again) will have problems, because they are
>> generating their "tomcat-dbcp.jar"
>> from commons-pool and commons-dbcp sources. They download these two
>> sources bundle,
>> change package names and merge them into one archive. If commons-dbcp
>> sources will be
>> jdbc4 compatible, they will have to repeat your 1. step above.
>> I wonder if it is possible to split commons-dbcp code base into two
>> modules and build them
>> entirely in Maven.
>>    
>
> You will always have an Ant task to perform the source generation of the
> "conditional" compilation. The trunk builds only with JDBC4, the Ant task
> has to run before building against JDBC3.
>
>  
So I wrote about splitting the codebase into two modules. Lately I'm
creating some library
with jdbc wrappers so I have the same problem. I wrote it against jdbc3 API.
Yesterday I have tested it against jdbc4. My solution it to create
second module for jdbc4
with classes extending the ones in jdbc3 module with additional methods
from jdbc4.
I've made two test modules: for java 1.5 and for Java 1.6 (enforced with
maven-enforcer-plugin).
Both test modules test both base modules and it works.

My modules:
jdbc3 - jdbc3 wrappers, module compiled with Java 1.5
jdbc4 - jdbc4 wrappers extending jdbc3 wrappers compiled with Java 1.6
java15-tests - tests for jdbc3 and jdbc4 modules compiled and run on
Java 1.5
java16-tests - tests for jdbc3 and jdbc4 modules compiled and run on
Java 1.6
Both java15-tests and java16-tests work so
it is possible to follow this way.

>> I made some simple tests. I could upload it somewhere
>> for you.
>>    
>
> You might use the -source artifact as dependency in the second module and
> unpack it with the dependency plugin and use then the Ant task to prepare
> the sources.
>  
I don't like it, but technically it's trivial. You will have problems
how to marriage it with IDE
developing.
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>  

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

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Phil Steitz
In reply to this post by Jörg Schaible
Jörg Schaible wrote:

> Hi Paul,
>
> Paul Benedict wrote at Donnerstag, 26. November 2009 05:03:
>
>> When I was patching Hibernate, they needed different sources because
>> of JDBC3/4 incompatibility. It just wasn't possible to compile for
>> both dependencies.
>>
>> I just checked with Brett Porter of Maven. He says that if the sources
>> are identical, you can use qualifiers; otherwise it would conflict
>> when you generate sources/javadocs/tests. You couldn't publish
>> different sources/etc. once the qualifier is used -- makes sense you
>> can't append more than one qualifier.
>>
>> Based on this advice, I revert to my previous advice and say they
>> should be separate artifactIds with no qualifiers.
>
> 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.  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.

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.

Phil


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

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

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Mark Thomas
In reply to this post by Grzegorz S?owikowski
Grzegorz Słowikowski wrote:
> 2. I agree with Jorg that the JDBC3 version should be the natural
> continuation of previous
> versions, so commons-dbcp:commons-dbcp:1.3 would be for JDBC3, not JDBC4.
> I know that Tomcat developers are waiting for new version of
> commons-dbcp because of some leaks
> in current commons-pool version (if I remember). Tomcat6 has Java5 as a
> minimum. I thing, they
> will not use jdbc4 version of commons-dbcp.

Tomcat is already using pool 1.5.x.

As far as dbcp goes, Tomcat uses the source so what happens with the binaries
won't affect Tomcat. The intention is that dbcp as embedded in Tomcat will
support JDBC4.

Mark


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

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]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Jörg Schaible
Hi Phil,

Phil Steitz wrote at Donnerstag, 26. November 2009 17:12:

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

Well, the point was, that such a dbcp-1.3.jar is no longer backward
compatible to a dbcp-1.2.x.jar. Therefore I proposed the change of the
artifactId for the JDBC4 version in first place. And here are the Maven
users affected ;-)

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

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

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

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

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Phil Steitz
In reply to this post by Jörg Schaible
Jörg Schaible wrote:

> Hi Phil,
>
> Phil Steitz wrote at Donnerstag, 26. November 2009 17:12:
>
>> 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.
>
> Well, the point was, that such a dbcp-1.3.jar is no longer backward
> compatible to a dbcp-1.2.x.jar. Therefore I proposed the change of the
> artifactId for the JDBC4 version in first place. And here are the Maven
> users affected ;-)

Did you miss that I cut out the "commons" from the artifactId?

That way we have commons-dbcp-1.3.jar and dbcp-1.3.jar in the wild.
 I guess I liked "dbcp" better than "commons-dbcp4" for the new
artifactId.  IIUC, the only reason we have kept the "commons-" on
the relocated commons artifactIds for components moved thus far is
so the relocation poms will work.   Since we are not doing that
here, we can make a clean break and use what seems to me at least a
more natural artifactId.  As always, could be I am missing something.

Phil


>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


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

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

Phil Steitz
In reply to this post by Paul Benedict
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.
>>>
>>> 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]

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 4:39 PM, Phil Steitz <[hidden email]> wrote:

> Jörg Schaible wrote:
>> Hi Phil,
>>
>> Phil Steitz wrote at Donnerstag, 26. November 2009 17:12:
>>
>>> 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.
>>
>> Well, the point was, that such a dbcp-1.3.jar is no longer backward
>> compatible to a dbcp-1.2.x.jar. Therefore I proposed the change of the
>> artifactId for the JDBC4 version in first place. And here are the Maven
>> users affected ;-)
>
> Did you miss that I cut out the "commons" from the artifactId?
>
> That way we have commons-dbcp-1.3.jar and dbcp-1.3.jar in the wild.
>  I guess I liked "dbcp" better than "commons-dbcp4" for the new
> artifactId.  IIUC, the only reason we have kept the "commons-" on
> the relocated commons artifactIds for components moved thus far is
> so the relocation poms will work.   Since we are not doing that
> here, we can make a clean break and use what seems to me at least a
> more natural artifactId.  As always, could be I am missing something.

This makes sense for people who consume the jars via maven since our
groupid identifies the producer and the m2 repository is organised as
that way - but oputside of maven I think retaining "commons" in the
jar name (and therefore artifactId) makes better sense since it groups
jars from our project together and makes it easier for people to
realise the source of the jar. And I think its better to be consistent
accross commons.

Niall

> Phil
>
>
>>
>> - 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 Phil Steitz
Phil Steitz wrote at Donnerstag, 26. November 2009 17:39:

[snip]
 
> Did you miss that I cut out the "commons" from the artifactId?

Yes, I missed it :D

> That way we have commons-dbcp-1.3.jar and dbcp-1.3.jar in the wild.
>  I guess I liked "dbcp" better than "commons-dbcp4" for the new
> artifactId.  IIUC, the only reason we have kept the "commons-" on
> the relocated commons artifactIds for components moved thus far is
> so the relocation poms will work.   Since we are not doing that
> here, we can make a clean break and use what seems to me at least a
> more natural artifactId.  As always, could be I am missing something.

No, you're totally right, "dbcp" and "commons-dbcp4" are equal from the
technical point of view. However, I feel a bit like Niall here dropping
"commons-" as prefix. But that's just me, we're both simply pressed by the
necessity to have a different name.

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

> On Thu, Nov 26, 2009 at 4:39 PM, Phil Steitz <[hidden email]> wrote:
>> Jörg Schaible wrote:
>>> Hi Phil,
>>>
>>> Phil Steitz wrote at Donnerstag, 26. November 2009 17:12:
>>>
>>>> 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.
>>> Well, the point was, that such a dbcp-1.3.jar is no longer backward
>>> compatible to a dbcp-1.2.x.jar. Therefore I proposed the change of the
>>> artifactId for the JDBC4 version in first place. And here are the Maven
>>> users affected ;-)
>> Did you miss that I cut out the "commons" from the artifactId?
>>
>> That way we have commons-dbcp-1.3.jar and dbcp-1.3.jar in the wild.
>>  I guess I liked "dbcp" better than "commons-dbcp4" for the new
>> artifactId.  IIUC, the only reason we have kept the "commons-" on
>> the relocated commons artifactIds for components moved thus far is
>> so the relocation poms will work.   Since we are not doing that
>> here, we can make a clean break and use what seems to me at least a
>> more natural artifactId.  As always, could be I am missing something.
>
> This makes sense for people who consume the jars via maven since our
> groupid identifies the producer and the m2 repository is organised as
> that way - but oputside of maven I think retaining "commons" in the
> jar name (and therefore artifactId) makes better sense since it groups
> jars from our project together and makes it easier for people to
> realise the source of the jar. And I think its better to be consistent
> accross commons.

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

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

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]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

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

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

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

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] 1.3 release packaging - take two

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

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

PS: Since you have a 2.0 planned, perhaps you only want to change the
groupId once you increment the major version?

Paul

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

> Niall Pemberton wrote:
>> On Thu, Nov 26, 2009 at 4:39 PM, Phil Steitz <[hidden email]> wrote:
>>> Jörg Schaible wrote:
>>>> Hi Phil,
>>>>
>>>> Phil Steitz wrote at Donnerstag, 26. November 2009 17:12:
>>>>
>>>>> 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.
>>>> Well, the point was, that such a dbcp-1.3.jar is no longer backward
>>>> compatible to a dbcp-1.2.x.jar. Therefore I proposed the change of the
>>>> artifactId for the JDBC4 version in first place. And here are the Maven
>>>> users affected ;-)
>>> Did you miss that I cut out the "commons" from the artifactId?
>>>
>>> That way we have commons-dbcp-1.3.jar and dbcp-1.3.jar in the wild.
>>>  I guess I liked "dbcp" better than "commons-dbcp4" for the new
>>> artifactId.  IIUC, the only reason we have kept the "commons-" on
>>> the relocated commons artifactIds for components moved thus far is
>>> so the relocation poms will work.   Since we are not doing that
>>> here, we can make a clean break and use what seems to me at least a
>>> more natural artifactId.  As always, could be I am missing something.
>>
>> This makes sense for people who consume the jars via maven since our
>> groupid identifies the producer and the m2 repository is organised as
>> that way - but oputside of maven I think retaining "commons" in the
>> jar name (and therefore artifactId) makes better sense since it groups
>> jars from our project together and makes it easier for people to
>> realise the source of the jar. And I think its better to be consistent
>> accross commons.
>
> 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
>>
>> Niall
>>
>>> Phil
>>>
>>>
>>>> - 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

Paul Benedict
In reply to this post by Niall Pemberton
I am +1 with Niall on two separate releases.

On Thu, Nov 26, 2009 at 11:47 AM, Niall Pemberton
<[hidden email]> 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.
>
> 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
>
>> 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]

1234