You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2009/11/25 22:58:00 UTC
[dbcp] 1.3 release packaging - take two
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
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Phil Steitz <ph...@gmail.com>.
Olivier Lamy wrote:
> Hi Folks,
> If you change groupId could you please provide a relocation pom in the
> old groupId
> commons-dbcp:commons-dbcp:1.3 -> org.apache.commons:commons-dbcp-jdbc3:1.3
Will do if we decide to go that route.
Phil
>
> --
> Olivier
>
> 2009/11/26 Phil Steitz <ph...@gmail.com>:
>> Paul Benedict 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
>>>
>>> What you have, simply, is, different artifacts.
>> Makes sense. Thanks.
>>
>> Keep the same groupId
>>> and version, just alter the artifact names.
>> What I was trying to avoid by moving the groupId to
>> org.apache.commons for the JDBC 4 artifact was 1.4-1.5 users
>> unwittingly upgrading to 1.3 and blowing up. This is also a change
>> we need to make at some point.
>>
>> Phil
>>> 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 <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Olivier Lamy <ol...@apache.org>.
Hi Folks,
If you change groupId could you please provide a relocation pom in the
old groupId
commons-dbcp:commons-dbcp:1.3 -> org.apache.commons:commons-dbcp-jdbc3:1.3
--
Olivier
2009/11/26 Phil Steitz <ph...@gmail.com>:
> Paul Benedict 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
>>
>> What you have, simply, is, different artifacts.
>
> Makes sense. Thanks.
>
> Keep the same groupId
>> and version, just alter the artifact names.
>
> What I was trying to avoid by moving the groupId to
> org.apache.commons for the JDBC 4 artifact was 1.4-1.5 users
> unwittingly upgrading to 1.3 and blowing up. This is also a change
> we need to make at some point.
>
> Phil
>>
>> 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 <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Olivier
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Phil Steitz <ph...@gmail.com>.
Paul Benedict 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
>
> What you have, simply, is, different artifacts.
Makes sense. Thanks.
Keep the same groupId
> and version, just alter the artifact names.
What I was trying to avoid by moving the groupId to
org.apache.commons for the JDBC 4 artifact was 1.4-1.5 users
unwittingly upgrading to 1.3 and blowing up. This is also a change
we need to make at some point.
Phil
>
> 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 <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Mark Thomas <ma...@apache.org>.
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Grzegorz Słowikowski <gs...@gmail.com>.
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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Jörg Schaible <jo...@gmx.de>.
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Grzegorz Słowikowski <gs...@gmail.com>.
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
>> <ni...@gmail.com> wrote:
>>
>>> On Thu, Nov 26, 2009 at 12:46 AM, Paul Benedict <pb...@apache.org> 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 <ph...@gmail.com> wrote:
>>>>
>>>>> Niall Pemberton wrote:
>>>>>
>>>>>> On Wed, Nov 25, 2009 at 11:39 PM, Niall Pemberton
>>>>>> <ni...@gmail.com> wrote:
>>>>>>
>>>>>>> On Wed, Nov 25, 2009 at 11:31 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Niall Pemberton wrote:
>>>>>>>>
>>>>>>>>> On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict <pb...@apache.org> 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 <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Phil Steitz <ph...@gmail.com>.
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)
This seems to work. If there are no objections, I will cut an RC
between veggie turkey bites tomorrow using this approach.
Phil
>
> Paul
>
> On Wed, Nov 25, 2009 at 6:51 PM, Niall Pemberton
> <ni...@gmail.com> wrote:
>> On Thu, Nov 26, 2009 at 12:46 AM, Paul Benedict <pb...@apache.org> 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 <ph...@gmail.com> wrote:
>>>> Niall Pemberton wrote:
>>>>> On Wed, Nov 25, 2009 at 11:39 PM, Niall Pemberton
>>>>> <ni...@gmail.com> wrote:
>>>>>> On Wed, Nov 25, 2009 at 11:31 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>>>> Niall Pemberton wrote:
>>>>>>>> On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict <pb...@apache.org> 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 <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Jörg Schaible <jo...@gmx.de>.
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Paul Benedict <pb...@apache.org>.
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 <ph...@gmail.com> wrote:
> Niall Pemberton wrote:
>> On Thu, Nov 26, 2009 at 5:46 PM, Niall Pemberton
>> <ni...@gmail.com> wrote:
>>> On Thu, Nov 26, 2009 at 4:57 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>> Paul Benedict wrote:
>>>>> Oops.. I meant minor version bumps ;-)
>>>>>
>>>>> On Thu, Nov 26, 2009 at 10:35 AM, Paul Benedict <pb...@apache.org> 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 <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Niall Pemberton <ni...@gmail.com>.
On Thu, Nov 26, 2009 at 5:55 PM, Phil Steitz <ph...@gmail.com> wrote:
> Niall Pemberton wrote:
>> On Thu, Nov 26, 2009 at 5:46 PM, Niall Pemberton
>> <ni...@gmail.com> wrote:
>>> On Thu, Nov 26, 2009 at 4:57 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>> Paul Benedict wrote:
>>>>> Oops.. I meant minor version bumps ;-)
>>>>>
>>>>> On Thu, Nov 26, 2009 at 10:35 AM, Paul Benedict <pb...@apache.org> 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 <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Phil Steitz <ph...@gmail.com>.
Niall Pemberton wrote:
> On Thu, Nov 26, 2009 at 5:46 PM, Niall Pemberton
> <ni...@gmail.com> wrote:
>> On Thu, Nov 26, 2009 at 4:57 PM, Phil Steitz <ph...@gmail.com> wrote:
>>> Paul Benedict wrote:
>>>> Oops.. I meant minor version bumps ;-)
>>>>
>>>> On Thu, Nov 26, 2009 at 10:35 AM, Paul Benedict <pb...@apache.org> 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 <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Jörg Schaible <jo...@gmx.de>.
Paul Benedict wrote:
> I am +1 with Niall on two separate releases.
+1
Me too
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Paul Benedict <pb...@apache.org>.
I am +1 with Niall on two separate releases.
On Thu, Nov 26, 2009 at 11:47 AM, Niall Pemberton
<ni...@gmail.com> wrote:
> On Thu, Nov 26, 2009 at 5:46 PM, Niall Pemberton
> <ni...@gmail.com> wrote:
>> On Thu, Nov 26, 2009 at 4:57 PM, Phil Steitz <ph...@gmail.com> wrote:
>>> Paul Benedict wrote:
>>>> Oops.. I meant minor version bumps ;-)
>>>>
>>>> On Thu, Nov 26, 2009 at 10:35 AM, Paul Benedict <pb...@apache.org> 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 <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Niall Pemberton <ni...@gmail.com>.
On Thu, Nov 26, 2009 at 5:46 PM, Niall Pemberton
<ni...@gmail.com> wrote:
> On Thu, Nov 26, 2009 at 4:57 PM, Phil Steitz <ph...@gmail.com> wrote:
>> Paul Benedict wrote:
>>> Oops.. I meant minor version bumps ;-)
>>>
>>> On Thu, Nov 26, 2009 at 10:35 AM, Paul Benedict <pb...@apache.org> 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 <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Niall Pemberton <ni...@gmail.com>.
On Thu, Nov 26, 2009 at 4:57 PM, Phil Steitz <ph...@gmail.com> wrote:
> Paul Benedict wrote:
>> Oops.. I meant minor version bumps ;-)
>>
>> On Thu, Nov 26, 2009 at 10:35 AM, Paul Benedict <pb...@apache.org> 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 <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Phil Steitz <ph...@gmail.com>.
Paul Benedict wrote:
> Oops.. I meant minor version bumps ;-)
>
> On Thu, Nov 26, 2009 at 10:35 AM, Paul Benedict <pb...@apache.org> 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 <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Paul Benedict <pb...@apache.org>.
Oops.. I meant minor version bumps ;-)
On Thu, Nov 26, 2009 at 10:35 AM, Paul Benedict <pb...@apache.org> 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 <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Paul Benedict <pb...@apache.org>.
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 <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by sebb <se...@gmail.com>.
On 28/11/2009, Niall Pemberton <ni...@gmail.com> wrote:
> 2009/11/28 Phil Steitz <ph...@gmail.com>:
>
> > Niall Pemberton wrote:
> >> 2009/11/27 Phil Steitz <ph...@gmail.com>:
> >>> Niall Pemberton wrote:
> >>>> 2009/11/27 Phil Steitz <ph...@gmail.com>:
> >>>>> Niall Pemberton wrote:
> >>>>>> On Fri, Nov 27, 2009 at 8:47 AM, Jörg Schaible <jo...@gmx.de> wrote:
> >>>>>>> Hi Grzegorz,
> >>>>>>>
> >>>>>>> Grzegorz Słowikowski wrote at Freitag, 27. November 2009 09:04:
> >>>>>>>
> >>>>>>>> Phil Steitz wrote:
> >>>>>>>>> Niall Pemberton wrote:
> >>>>>>>>>
> >>>>>>>> ...
> >>>>>>>>> Good points - so what is your recommendation?
> >>>>>>>>>
> >>>>>>>>> org.apache.commons:commons-dbcp4:1.3
> >>>>>>>>> commons-dbcp:commons-dbcp:1.3
> >>>>>>>>>
> >>>>>>>>> or
> >>>>>>>>>
> >>>>>>>>> org.apache.commons:commons-dbcp:1.3
> >>>>>>>>> commons-dbcp:commons-dbcp:1.3
> >>>>>>>>>
> >>>>>>>>> or
> >>>>>>>>>
> >>>>>>>>> org.apache.commons:commons-dbcp:1.4
> >>>>>>>>> commons-dbcp:commons-dbcp:1.3
> >>>>>>>>>
> >>>>>>>>> or?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Phil
> >>>>>>>>>
> >>>>>>>> ...
> >>>>>>>> Think about war files, what you will have in WEB-INF/lib. You CANNOT
> >>>>>>>> have (accidentally,
> >>>>>>>> from transitive dependencies) commons-dbcp and commond-dbcp4 together in
> >>>>>>>> the class path,
> >>>>>>>> so the first proposal is not good.
> >>>>>>> This can happen for all three proposals. Since the groupId is different
> >>>>>>> Maven handles the two artifacts in all three cases as unrelated. If the
> >>>>>>> artifact name for two distinct artifacts clash, it will automatically
> >>>>>>> prepend the groupId for such cases like the war plugin.
> >>>>>>>
> >>>>>>>
> >>>>>>>> If you release jdbc3 and jdbc4 artifacts from the same release process
> >>>>>>>> (some code commented for
> >>>>>>>> jdbc3 version) - this is one release for me, so the version numbers
> >>>>>>>> should be identical.
> >>>>>>> Actually we have two incompatible versions. If someone depends (by
> >>>>>>> transitive deps or directly) on both versions, he has always a problem.
> >>>>>>> Changing the groupId for one will simply expose the problem more obviously,
> >>>>>>> because both jars will end up in the dependencies - otherwise Maven version
> >>>>>>> resolution will silently chose one of them and drop the other one.
> >>>>>>>
> >>>>>>>> But I see you will probably prefer releasing separately and creating
> >>>>>>>> branch for 1.3.x patch releases.
> >>>>>>>> I would prefer this way too. In this situation we have version 1.3
> >>>>>>>> backward compatible and version
> >>>>>>>> 1.4 not compatible. Because incompatibility comes not from your API
> >>>>>>>> changes but from changes
> >>>>>>>> inside Java API, then I say you don't have to change version numbering
> >>>>>>>> to 2.x.x (change on the
> >>>>>>>> first position).
> >>>>>>>> I don't remember what's going on inside Maven build of war artifact if
> >>>>>>>> you have two dependencies
> >>>>>>>> with different group ids and the same artifact ids. They are different
> >>>>>>>> artifacts and there is no
> >>>>>>>> version resolution between them. Maven war plugin prepares war content
> >>>>>>>> in "target/{artifactId}-{version}" directory before creating war file,
> >>>>>>>> so one of these files will
> >>>>>>>> overwrite the other I think.
> >>>>>>> As explained - no.
> >>>>>>>
> >>>>>>>> If some other build tool would create war archive on the fly, both files
> >>>>>>>> could be packaged
> >>>>>>>> because there are no constraints on unique file names inside jars/wars
> >>>>>>>> and this would be very bad!
> >>>>>>> Therefore we want to change the version for the JDBC version4, so we end up
> >>>>>>> for those tools with two distinguishable names: commons-dbcp-1.3.jar and
> >>>>>>> commons-dbcp-1.4.jar
> >>>>>>>
> >>>>>>>> Additionally I remember some discussions on Maven lists against
> >>>>>>>> relocations (some Apache
> >>>>>>>> Commons project changed its groupId to "org.apache.commons", and
> >>>>>>>> reverted this change very
> >>>>>>>> soon), but I don't remember the exact problem. Maybe you could ask Brett
> >>>>>>>> Porter or Jason val Zyl.
> >>>>>>> No relocations involved here.
> >>>>>>>
> >>>>>>>> IMHO the safest and most conservative naming convention would be:
> >>>>>>>>
> >>>>>>>> commons-dbcp:commons-dbcp:1.4
> >>>>>>>> commons-dbcp:commons-dbcp:1.3
> >>>>>>> No, because this would actually make the JDBC4 version available as an
> >>>>>>> upgrade for the JDBC3 one. This is the scenario we have to avoid.
> >>>>>> I really don't understand this - this is exactly the scenario we want.
> >>>>>> Doing it this way DBCP 1.4 will just be an upgrade for DBCP 1.3 with
> >>>>>> the additional methods introduced by JDBC 4. How is this any different
> >>>>>> from any later version of a component that adds additional methods and
> >>>>>> relies on the API of a later version of the JDK?
> >>>>> The problem is that it is not backward compatible. You can see this
> >>>>> using the test-jar.xml ant build in trunk. Build a jar using JDK
> >>>>> 1.6 and then try to build the tests and execute them against this
> >>>> I did, with the source/target set to JDK 1.6 - so the minimum JDK for
> >>>> DBCP 1.4 is JDK 1.6. That way anyone who wants to depend on DBCP 1.4
> >>>> will have to be on JDK 1.6. The mistake IMO is to build DBCP 1.4 using
> >>>> JDK 1.6 while setting the source/traget JDK to < JDK 1.6
> >>>>
> >>> Agreed, but those on 1.4 or 1.5 will still get runtime errors if
> >>> they inadvertently get "upgraded" unless I am missing something
> >>> here. Running against the 1.4 jar you posted, I now get bad class
> >>> file errors.
> >>
> >> For a project to depend on DBCP 1.4 then they will have to require JDK
> >> 1.6. Anyone who depends on that project will also therefore have to
> >> require JDK 1.6. I guess its probably possible to have a project built
> >> on JDK 1.6, but with a source/target set to a previous JDK and a
> >> dependency on DBCP 1.4 - but this is broken since with DBCP 1.4 it
> >> will (as you say) only ever run on JDK 1.6.
> >>
> >> Anyway, this is just a build issue that someone will have to sort out.
> >> If that could happen (which tbh I doubt) then they will just have to
> >> revert back to DBCP 1.3. This is true of any of our components that
> >> have "upgraded" their minimum JDK requirements. In this scenario
> >> though its not an issue because we will be providing a DBCP 1.3
> >> solution that they can revert to that has all the fixes of DBCP 1.4,
> >> just without the JDBC 4 features.
> >>
> >
> > Thanks, Niall. Sorry I was not clear and a little slow to come
> > around to seeing the full picture here. I now understand and agree
> > with the approach - including not changing the groupId - that you
> > have proposed. I have a couple of small things to fix and then I
> > will cut RCs for both 1.3 and 1.4.
>
>
> Great, let me know if theres anything you want me to do to help.
>
> When I created a test branch I added the following step to the ant
> build file to update the sources in place:
>
> http://tinyurl.com/ykhafzb
>
> Should we add this to build.xml in trunk?
>
I think it needs a comment as to when to use it, as it changes the SVN
working copy, for example:
<!-- This target can be used to remove JDBC4-dependent code from the
current working copy e.g. in order to produce a JDBC3-only branch -->
> Niall
>
>
> > Phil
> >
> >>> Phil
> >>>
> >>>
> >>>> Niall
> >>>>
> >>>>> jar using 1.4 or 1.5 and you will get runtime errors. Sebb chased
> >>>>>
> >>>>> at least one of these down as being due to an import
> >>>>> (SQLClientInfoException) in the jdbc4 code.
> >>>>>
> >>>>> That is the reason I proposed changing the groupId, because I did
> >>>>> not want client apps to blow up with runtime errors when "latest
> >>>>> version" resolution of range specifiers grab 1.4 for them when they
> >>>>> are running jdk 1.4 or 1.5.
> >>>>>
> >>>>> Phil
> >>>>>> Niall
> >>>>>>
> >>>>>>>> In this situation JDBC4 version always wins. It means you know what
> >>>>>>>> version will land in your
> >>>>>>>> war file if you have both dependencies in your project and don't specify
> >>>>>>>> your preferred version
> >>>>>>>> in the pom.xml file.
> >>>>>>> No, if you know what you need, you can adjust the groupId for the JDBC4
> >>>>>>> version. If your dependencies still contains the other one, you have a
> >>>>>>> problem anyway.
> >>>>>>>
> >>>>>>> - Jörg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Phil Steitz <ph...@gmail.com>.
Jörg Schaible wrote:
> Niall Pemberton wrote:
>
>> 2009/11/28 Phil Steitz <ph...@gmail.com>:
>
> [snip]
>
>>> I think adding this to the build.xml in trunk will be confusing. I
>>> agree with Sebb that if we do that we need to comment it. Since we
>>> are going to have to have a branch to cut the 1.3 release from and
>>> we also need to change the version number in the build files there,
>>> I was thinking it might be better to create a build.xml just for 1.3
>>> that eliminates the nojdbc4 stuff and executes the new goal as part
>>> of the build. I am pretty sure the filtering operation is
>>> idempotent, so should not be a problem executing repeatedly and this
>>> would eliminate the possibility of forgetting to do it. This and
>>> the modified (version change only) pom.xml would replace build.xml,
>>> pom.xml in the branch.
>
> It's not enough to adjust the version in the POM, you have to adjust the SCM
> URLs also to release with Maven from the branch.
>
Thanks for reminding me of this. I was not planning to use the
release plugin to perform the release, but I will adjust the scm URLs.
Phil
>>> The process for cutting 1.3.1/1.4.1 would then be
>>> 0) create a 1.3.1 branch from trunk
>>> 1) copy build.xml, pom.xml from 1.3 branch (alternatively, we could
>>> maintain build.xml.1.3, pom.xml.1.3 in trunk and rename in the branch).
>>> 2) backport any pom or build.xml changes from trunk to the 1.3
>>> versions in the branch
>>> 3) normal release stuff in trunk for 1.4, branch for 1.3
>> Sounds good to me. I don't mind either option for build.xml/pom.xml -
>> whichever you prefer.
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Jörg Schaible <jo...@gmx.de>.
Niall Pemberton wrote:
> 2009/11/28 Phil Steitz <ph...@gmail.com>:
[snip]
>> I think adding this to the build.xml in trunk will be confusing. I
>> agree with Sebb that if we do that we need to comment it. Since we
>> are going to have to have a branch to cut the 1.3 release from and
>> we also need to change the version number in the build files there,
>> I was thinking it might be better to create a build.xml just for 1.3
>> that eliminates the nojdbc4 stuff and executes the new goal as part
>> of the build. I am pretty sure the filtering operation is
>> idempotent, so should not be a problem executing repeatedly and this
>> would eliminate the possibility of forgetting to do it. This and
>> the modified (version change only) pom.xml would replace build.xml,
>> pom.xml in the branch.
It's not enough to adjust the version in the POM, you have to adjust the SCM
URLs also to release with Maven from the branch.
>> The process for cutting 1.3.1/1.4.1 would then be
>> 0) create a 1.3.1 branch from trunk
>> 1) copy build.xml, pom.xml from 1.3 branch (alternatively, we could
>> maintain build.xml.1.3, pom.xml.1.3 in trunk and rename in the branch).
>> 2) backport any pom or build.xml changes from trunk to the 1.3
>> versions in the branch
>> 3) normal release stuff in trunk for 1.4, branch for 1.3
>
> Sounds good to me. I don't mind either option for build.xml/pom.xml -
> whichever you prefer.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Niall Pemberton <ni...@gmail.com>.
2009/11/28 Phil Steitz <ph...@gmail.com>:
> Niall Pemberton wrote:
>> 2009/11/28 Phil Steitz <ph...@gmail.com>:
>>> Niall Pemberton wrote:
>>>> 2009/11/27 Phil Steitz <ph...@gmail.com>:
>>>>> Niall Pemberton wrote:
>>>>>> 2009/11/27 Phil Steitz <ph...@gmail.com>:
>>>>>>> Niall Pemberton wrote:
>>>>>>>> On Fri, Nov 27, 2009 at 8:47 AM, Jörg Schaible <jo...@gmx.de> wrote:
>>>>>>>>> Hi Grzegorz,
>>>>>>>>>
>>>>>>>>> Grzegorz Słowikowski wrote at Freitag, 27. November 2009 09:04:
>>>>>>>>>
>>>>>>>>>> Phil Steitz wrote:
>>>>>>>>>>> Niall Pemberton wrote:
>>>>>>>>>>>
>>>>>>>>>> ...
>>>>>>>>>>> Good points - so what is your recommendation?
>>>>>>>>>>>
>>>>>>>>>>> org.apache.commons:commons-dbcp4:1.3
>>>>>>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>>>>>>
>>>>>>>>>>> or
>>>>>>>>>>>
>>>>>>>>>>> org.apache.commons:commons-dbcp:1.3
>>>>>>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>>>>>>
>>>>>>>>>>> or
>>>>>>>>>>>
>>>>>>>>>>> org.apache.commons:commons-dbcp:1.4
>>>>>>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>>>>>>
>>>>>>>>>>> or?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Phil
>>>>>>>>>>>
>>>>>>>>>> ...
>>>>>>>>>> Think about war files, what you will have in WEB-INF/lib. You CANNOT
>>>>>>>>>> have (accidentally,
>>>>>>>>>> from transitive dependencies) commons-dbcp and commond-dbcp4 together in
>>>>>>>>>> the class path,
>>>>>>>>>> so the first proposal is not good.
>>>>>>>>> This can happen for all three proposals. Since the groupId is different
>>>>>>>>> Maven handles the two artifacts in all three cases as unrelated. If the
>>>>>>>>> artifact name for two distinct artifacts clash, it will automatically
>>>>>>>>> prepend the groupId for such cases like the war plugin.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> If you release jdbc3 and jdbc4 artifacts from the same release process
>>>>>>>>>> (some code commented for
>>>>>>>>>> jdbc3 version) - this is one release for me, so the version numbers
>>>>>>>>>> should be identical.
>>>>>>>>> Actually we have two incompatible versions. If someone depends (by
>>>>>>>>> transitive deps or directly) on both versions, he has always a problem.
>>>>>>>>> Changing the groupId for one will simply expose the problem more obviously,
>>>>>>>>> because both jars will end up in the dependencies - otherwise Maven version
>>>>>>>>> resolution will silently chose one of them and drop the other one.
>>>>>>>>>
>>>>>>>>>> But I see you will probably prefer releasing separately and creating
>>>>>>>>>> branch for 1.3.x patch releases.
>>>>>>>>>> I would prefer this way too. In this situation we have version 1.3
>>>>>>>>>> backward compatible and version
>>>>>>>>>> 1.4 not compatible. Because incompatibility comes not from your API
>>>>>>>>>> changes but from changes
>>>>>>>>>> inside Java API, then I say you don't have to change version numbering
>>>>>>>>>> to 2.x.x (change on the
>>>>>>>>>> first position).
>>>>>>>>>> I don't remember what's going on inside Maven build of war artifact if
>>>>>>>>>> you have two dependencies
>>>>>>>>>> with different group ids and the same artifact ids. They are different
>>>>>>>>>> artifacts and there is no
>>>>>>>>>> version resolution between them. Maven war plugin prepares war content
>>>>>>>>>> in "target/{artifactId}-{version}" directory before creating war file,
>>>>>>>>>> so one of these files will
>>>>>>>>>> overwrite the other I think.
>>>>>>>>> As explained - no.
>>>>>>>>>
>>>>>>>>>> If some other build tool would create war archive on the fly, both files
>>>>>>>>>> could be packaged
>>>>>>>>>> because there are no constraints on unique file names inside jars/wars
>>>>>>>>>> and this would be very bad!
>>>>>>>>> Therefore we want to change the version for the JDBC version4, so we end up
>>>>>>>>> for those tools with two distinguishable names: commons-dbcp-1.3.jar and
>>>>>>>>> commons-dbcp-1.4.jar
>>>>>>>>>
>>>>>>>>>> Additionally I remember some discussions on Maven lists against
>>>>>>>>>> relocations (some Apache
>>>>>>>>>> Commons project changed its groupId to "org.apache.commons", and
>>>>>>>>>> reverted this change very
>>>>>>>>>> soon), but I don't remember the exact problem. Maybe you could ask Brett
>>>>>>>>>> Porter or Jason val Zyl.
>>>>>>>>> No relocations involved here.
>>>>>>>>>
>>>>>>>>>> IMHO the safest and most conservative naming convention would be:
>>>>>>>>>>
>>>>>>>>>> commons-dbcp:commons-dbcp:1.4
>>>>>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>>>> No, because this would actually make the JDBC4 version available as an
>>>>>>>>> upgrade for the JDBC3 one. This is the scenario we have to avoid.
>>>>>>>> I really don't understand this - this is exactly the scenario we want.
>>>>>>>> Doing it this way DBCP 1.4 will just be an upgrade for DBCP 1.3 with
>>>>>>>> the additional methods introduced by JDBC 4. How is this any different
>>>>>>>> from any later version of a component that adds additional methods and
>>>>>>>> relies on the API of a later version of the JDK?
>>>>>>> The problem is that it is not backward compatible. You can see this
>>>>>>> using the test-jar.xml ant build in trunk. Build a jar using JDK
>>>>>>> 1.6 and then try to build the tests and execute them against this
>>>>>> I did, with the source/target set to JDK 1.6 - so the minimum JDK for
>>>>>> DBCP 1.4 is JDK 1.6. That way anyone who wants to depend on DBCP 1.4
>>>>>> will have to be on JDK 1.6. The mistake IMO is to build DBCP 1.4 using
>>>>>> JDK 1.6 while setting the source/traget JDK to < JDK 1.6
>>>>>>
>>>>> Agreed, but those on 1.4 or 1.5 will still get runtime errors if
>>>>> they inadvertently get "upgraded" unless I am missing something
>>>>> here. Running against the 1.4 jar you posted, I now get bad class
>>>>> file errors.
>>>> For a project to depend on DBCP 1.4 then they will have to require JDK
>>>> 1.6. Anyone who depends on that project will also therefore have to
>>>> require JDK 1.6. I guess its probably possible to have a project built
>>>> on JDK 1.6, but with a source/target set to a previous JDK and a
>>>> dependency on DBCP 1.4 - but this is broken since with DBCP 1.4 it
>>>> will (as you say) only ever run on JDK 1.6.
>>>>
>>>> Anyway, this is just a build issue that someone will have to sort out.
>>>> If that could happen (which tbh I doubt) then they will just have to
>>>> revert back to DBCP 1.3. This is true of any of our components that
>>>> have "upgraded" their minimum JDK requirements. In this scenario
>>>> though its not an issue because we will be providing a DBCP 1.3
>>>> solution that they can revert to that has all the fixes of DBCP 1.4,
>>>> just without the JDBC 4 features.
>>>>
>>> Thanks, Niall. Sorry I was not clear and a little slow to come
>>> around to seeing the full picture here. I now understand and agree
>>> with the approach - including not changing the groupId - that you
>>> have proposed. I have a couple of small things to fix and then I
>>> will cut RCs for both 1.3 and 1.4.
>>
>> Great, let me know if theres anything you want me to do to help.
>>
>> When I created a test branch I added the following step to the ant
>> build file to update the sources in place:
>>
>> http://tinyurl.com/ykhafzb
>>
>> Should we add this to build.xml in trunk?
>>
>> Niall
>
> I think adding this to the build.xml in trunk will be confusing. I
> agree with Sebb that if we do that we need to comment it. Since we
> are going to have to have a branch to cut the 1.3 release from and
> we also need to change the version number in the build files there,
> I was thinking it might be better to create a build.xml just for 1.3
> that eliminates the nojdbc4 stuff and executes the new goal as part
> of the build. I am pretty sure the filtering operation is
> idempotent, so should not be a problem executing repeatedly and this
> would eliminate the possibility of forgetting to do it. This and
> the modified (version change only) pom.xml would replace build.xml,
> pom.xml in the branch.
>
> The process for cutting 1.3.1/1.4.1 would then be
> 0) create a 1.3.1 branch from trunk
> 1) copy build.xml, pom.xml from 1.3 branch (alternatively, we could
> maintain build.xml.1.3, pom.xml.1.3 in trunk and rename in the branch).
> 2) backport any pom or build.xml changes from trunk to the 1.3
> versions in the branch
> 3) normal release stuff in trunk for 1.4, branch for 1.3
Sounds good to me. I don't mind either option for build.xml/pom.xml -
whichever you prefer.
Niall
> Phil
>
>>
>>> Phil
>>>
>>>>> Phil
>>>>>
>>>>>
>>>>>> Niall
>>>>>>
>>>>>>> jar using 1.4 or 1.5 and you will get runtime errors. Sebb chased
>>>>>>>
>>>>>>> at least one of these down as being due to an import
>>>>>>> (SQLClientInfoException) in the jdbc4 code.
>>>>>>>
>>>>>>> That is the reason I proposed changing the groupId, because I did
>>>>>>> not want client apps to blow up with runtime errors when "latest
>>>>>>> version" resolution of range specifiers grab 1.4 for them when they
>>>>>>> are running jdk 1.4 or 1.5.
>>>>>>>
>>>>>>> Phil
>>>>>>>> Niall
>>>>>>>>
>>>>>>>>>> In this situation JDBC4 version always wins. It means you know what
>>>>>>>>>> version will land in your
>>>>>>>>>> war file if you have both dependencies in your project and don't specify
>>>>>>>>>> your preferred version
>>>>>>>>>> in the pom.xml file.
>>>>>>>>> No, if you know what you need, you can adjust the groupId for the JDBC4
>>>>>>>>> version. If your dependencies still contains the other one, you have a
>>>>>>>>> problem anyway.
>>>>>>>>>
>>>>>>>>> - Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Phil Steitz <ph...@gmail.com>.
Niall Pemberton wrote:
> 2009/11/28 Phil Steitz <ph...@gmail.com>:
>> Niall Pemberton wrote:
>>> 2009/11/27 Phil Steitz <ph...@gmail.com>:
>>>> Niall Pemberton wrote:
>>>>> 2009/11/27 Phil Steitz <ph...@gmail.com>:
>>>>>> Niall Pemberton wrote:
>>>>>>> On Fri, Nov 27, 2009 at 8:47 AM, Jörg Schaible <jo...@gmx.de> wrote:
>>>>>>>> Hi Grzegorz,
>>>>>>>>
>>>>>>>> Grzegorz Słowikowski wrote at Freitag, 27. November 2009 09:04:
>>>>>>>>
>>>>>>>>> Phil Steitz wrote:
>>>>>>>>>> Niall Pemberton wrote:
>>>>>>>>>>
>>>>>>>>> ...
>>>>>>>>>> Good points - so what is your recommendation?
>>>>>>>>>>
>>>>>>>>>> org.apache.commons:commons-dbcp4:1.3
>>>>>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>>>>>
>>>>>>>>>> or
>>>>>>>>>>
>>>>>>>>>> org.apache.commons:commons-dbcp:1.3
>>>>>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>>>>>
>>>>>>>>>> or
>>>>>>>>>>
>>>>>>>>>> org.apache.commons:commons-dbcp:1.4
>>>>>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>>>>>
>>>>>>>>>> or?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Phil
>>>>>>>>>>
>>>>>>>>> ...
>>>>>>>>> Think about war files, what you will have in WEB-INF/lib. You CANNOT
>>>>>>>>> have (accidentally,
>>>>>>>>> from transitive dependencies) commons-dbcp and commond-dbcp4 together in
>>>>>>>>> the class path,
>>>>>>>>> so the first proposal is not good.
>>>>>>>> This can happen for all three proposals. Since the groupId is different
>>>>>>>> Maven handles the two artifacts in all three cases as unrelated. If the
>>>>>>>> artifact name for two distinct artifacts clash, it will automatically
>>>>>>>> prepend the groupId for such cases like the war plugin.
>>>>>>>>
>>>>>>>>
>>>>>>>>> If you release jdbc3 and jdbc4 artifacts from the same release process
>>>>>>>>> (some code commented for
>>>>>>>>> jdbc3 version) - this is one release for me, so the version numbers
>>>>>>>>> should be identical.
>>>>>>>> Actually we have two incompatible versions. If someone depends (by
>>>>>>>> transitive deps or directly) on both versions, he has always a problem.
>>>>>>>> Changing the groupId for one will simply expose the problem more obviously,
>>>>>>>> because both jars will end up in the dependencies - otherwise Maven version
>>>>>>>> resolution will silently chose one of them and drop the other one.
>>>>>>>>
>>>>>>>>> But I see you will probably prefer releasing separately and creating
>>>>>>>>> branch for 1.3.x patch releases.
>>>>>>>>> I would prefer this way too. In this situation we have version 1.3
>>>>>>>>> backward compatible and version
>>>>>>>>> 1.4 not compatible. Because incompatibility comes not from your API
>>>>>>>>> changes but from changes
>>>>>>>>> inside Java API, then I say you don't have to change version numbering
>>>>>>>>> to 2.x.x (change on the
>>>>>>>>> first position).
>>>>>>>>> I don't remember what's going on inside Maven build of war artifact if
>>>>>>>>> you have two dependencies
>>>>>>>>> with different group ids and the same artifact ids. They are different
>>>>>>>>> artifacts and there is no
>>>>>>>>> version resolution between them. Maven war plugin prepares war content
>>>>>>>>> in "target/{artifactId}-{version}" directory before creating war file,
>>>>>>>>> so one of these files will
>>>>>>>>> overwrite the other I think.
>>>>>>>> As explained - no.
>>>>>>>>
>>>>>>>>> If some other build tool would create war archive on the fly, both files
>>>>>>>>> could be packaged
>>>>>>>>> because there are no constraints on unique file names inside jars/wars
>>>>>>>>> and this would be very bad!
>>>>>>>> Therefore we want to change the version for the JDBC version4, so we end up
>>>>>>>> for those tools with two distinguishable names: commons-dbcp-1.3.jar and
>>>>>>>> commons-dbcp-1.4.jar
>>>>>>>>
>>>>>>>>> Additionally I remember some discussions on Maven lists against
>>>>>>>>> relocations (some Apache
>>>>>>>>> Commons project changed its groupId to "org.apache.commons", and
>>>>>>>>> reverted this change very
>>>>>>>>> soon), but I don't remember the exact problem. Maybe you could ask Brett
>>>>>>>>> Porter or Jason val Zyl.
>>>>>>>> No relocations involved here.
>>>>>>>>
>>>>>>>>> IMHO the safest and most conservative naming convention would be:
>>>>>>>>>
>>>>>>>>> commons-dbcp:commons-dbcp:1.4
>>>>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>>> No, because this would actually make the JDBC4 version available as an
>>>>>>>> upgrade for the JDBC3 one. This is the scenario we have to avoid.
>>>>>>> I really don't understand this - this is exactly the scenario we want.
>>>>>>> Doing it this way DBCP 1.4 will just be an upgrade for DBCP 1.3 with
>>>>>>> the additional methods introduced by JDBC 4. How is this any different
>>>>>>> from any later version of a component that adds additional methods and
>>>>>>> relies on the API of a later version of the JDK?
>>>>>> The problem is that it is not backward compatible. You can see this
>>>>>> using the test-jar.xml ant build in trunk. Build a jar using JDK
>>>>>> 1.6 and then try to build the tests and execute them against this
>>>>> I did, with the source/target set to JDK 1.6 - so the minimum JDK for
>>>>> DBCP 1.4 is JDK 1.6. That way anyone who wants to depend on DBCP 1.4
>>>>> will have to be on JDK 1.6. The mistake IMO is to build DBCP 1.4 using
>>>>> JDK 1.6 while setting the source/traget JDK to < JDK 1.6
>>>>>
>>>> Agreed, but those on 1.4 or 1.5 will still get runtime errors if
>>>> they inadvertently get "upgraded" unless I am missing something
>>>> here. Running against the 1.4 jar you posted, I now get bad class
>>>> file errors.
>>> For a project to depend on DBCP 1.4 then they will have to require JDK
>>> 1.6. Anyone who depends on that project will also therefore have to
>>> require JDK 1.6. I guess its probably possible to have a project built
>>> on JDK 1.6, but with a source/target set to a previous JDK and a
>>> dependency on DBCP 1.4 - but this is broken since with DBCP 1.4 it
>>> will (as you say) only ever run on JDK 1.6.
>>>
>>> Anyway, this is just a build issue that someone will have to sort out.
>>> If that could happen (which tbh I doubt) then they will just have to
>>> revert back to DBCP 1.3. This is true of any of our components that
>>> have "upgraded" their minimum JDK requirements. In this scenario
>>> though its not an issue because we will be providing a DBCP 1.3
>>> solution that they can revert to that has all the fixes of DBCP 1.4,
>>> just without the JDBC 4 features.
>>>
>> Thanks, Niall. Sorry I was not clear and a little slow to come
>> around to seeing the full picture here. I now understand and agree
>> with the approach - including not changing the groupId - that you
>> have proposed. I have a couple of small things to fix and then I
>> will cut RCs for both 1.3 and 1.4.
>
> Great, let me know if theres anything you want me to do to help.
>
> When I created a test branch I added the following step to the ant
> build file to update the sources in place:
>
> http://tinyurl.com/ykhafzb
>
> Should we add this to build.xml in trunk?
>
> Niall
I think adding this to the build.xml in trunk will be confusing. I
agree with Sebb that if we do that we need to comment it. Since we
are going to have to have a branch to cut the 1.3 release from and
we also need to change the version number in the build files there,
I was thinking it might be better to create a build.xml just for 1.3
that eliminates the nojdbc4 stuff and executes the new goal as part
of the build. I am pretty sure the filtering operation is
idempotent, so should not be a problem executing repeatedly and this
would eliminate the possibility of forgetting to do it. This and
the modified (version change only) pom.xml would replace build.xml,
pom.xml in the branch.
The process for cutting 1.3.1/1.4.1 would then be
0) create a 1.3.1 branch from trunk
1) copy build.xml, pom.xml from 1.3 branch (alternatively, we could
maintain build.xml.1.3, pom.xml.1.3 in trunk and rename in the branch).
2) backport any pom or build.xml changes from trunk to the 1.3
versions in the branch
3) normal release stuff in trunk for 1.4, branch for 1.3
Phil
>
>> Phil
>>
>>>> Phil
>>>>
>>>>
>>>>> Niall
>>>>>
>>>>>> jar using 1.4 or 1.5 and you will get runtime errors. Sebb chased
>>>>>>
>>>>>> at least one of these down as being due to an import
>>>>>> (SQLClientInfoException) in the jdbc4 code.
>>>>>>
>>>>>> That is the reason I proposed changing the groupId, because I did
>>>>>> not want client apps to blow up with runtime errors when "latest
>>>>>> version" resolution of range specifiers grab 1.4 for them when they
>>>>>> are running jdk 1.4 or 1.5.
>>>>>>
>>>>>> Phil
>>>>>>> Niall
>>>>>>>
>>>>>>>>> In this situation JDBC4 version always wins. It means you know what
>>>>>>>>> version will land in your
>>>>>>>>> war file if you have both dependencies in your project and don't specify
>>>>>>>>> your preferred version
>>>>>>>>> in the pom.xml file.
>>>>>>>> No, if you know what you need, you can adjust the groupId for the JDBC4
>>>>>>>> version. If your dependencies still contains the other one, you have a
>>>>>>>> problem anyway.
>>>>>>>>
>>>>>>>> - Jörg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Niall Pemberton <ni...@gmail.com>.
2009/11/28 Phil Steitz <ph...@gmail.com>:
> Niall Pemberton wrote:
>> 2009/11/27 Phil Steitz <ph...@gmail.com>:
>>> Niall Pemberton wrote:
>>>> 2009/11/27 Phil Steitz <ph...@gmail.com>:
>>>>> Niall Pemberton wrote:
>>>>>> On Fri, Nov 27, 2009 at 8:47 AM, Jörg Schaible <jo...@gmx.de> wrote:
>>>>>>> Hi Grzegorz,
>>>>>>>
>>>>>>> Grzegorz Słowikowski wrote at Freitag, 27. November 2009 09:04:
>>>>>>>
>>>>>>>> Phil Steitz wrote:
>>>>>>>>> Niall Pemberton wrote:
>>>>>>>>>
>>>>>>>> ...
>>>>>>>>> Good points - so what is your recommendation?
>>>>>>>>>
>>>>>>>>> org.apache.commons:commons-dbcp4:1.3
>>>>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>>>>
>>>>>>>>> or
>>>>>>>>>
>>>>>>>>> org.apache.commons:commons-dbcp:1.3
>>>>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>>>>
>>>>>>>>> or
>>>>>>>>>
>>>>>>>>> org.apache.commons:commons-dbcp:1.4
>>>>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>>>>
>>>>>>>>> or?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Phil
>>>>>>>>>
>>>>>>>> ...
>>>>>>>> Think about war files, what you will have in WEB-INF/lib. You CANNOT
>>>>>>>> have (accidentally,
>>>>>>>> from transitive dependencies) commons-dbcp and commond-dbcp4 together in
>>>>>>>> the class path,
>>>>>>>> so the first proposal is not good.
>>>>>>> This can happen for all three proposals. Since the groupId is different
>>>>>>> Maven handles the two artifacts in all three cases as unrelated. If the
>>>>>>> artifact name for two distinct artifacts clash, it will automatically
>>>>>>> prepend the groupId for such cases like the war plugin.
>>>>>>>
>>>>>>>
>>>>>>>> If you release jdbc3 and jdbc4 artifacts from the same release process
>>>>>>>> (some code commented for
>>>>>>>> jdbc3 version) - this is one release for me, so the version numbers
>>>>>>>> should be identical.
>>>>>>> Actually we have two incompatible versions. If someone depends (by
>>>>>>> transitive deps or directly) on both versions, he has always a problem.
>>>>>>> Changing the groupId for one will simply expose the problem more obviously,
>>>>>>> because both jars will end up in the dependencies - otherwise Maven version
>>>>>>> resolution will silently chose one of them and drop the other one.
>>>>>>>
>>>>>>>> But I see you will probably prefer releasing separately and creating
>>>>>>>> branch for 1.3.x patch releases.
>>>>>>>> I would prefer this way too. In this situation we have version 1.3
>>>>>>>> backward compatible and version
>>>>>>>> 1.4 not compatible. Because incompatibility comes not from your API
>>>>>>>> changes but from changes
>>>>>>>> inside Java API, then I say you don't have to change version numbering
>>>>>>>> to 2.x.x (change on the
>>>>>>>> first position).
>>>>>>>> I don't remember what's going on inside Maven build of war artifact if
>>>>>>>> you have two dependencies
>>>>>>>> with different group ids and the same artifact ids. They are different
>>>>>>>> artifacts and there is no
>>>>>>>> version resolution between them. Maven war plugin prepares war content
>>>>>>>> in "target/{artifactId}-{version}" directory before creating war file,
>>>>>>>> so one of these files will
>>>>>>>> overwrite the other I think.
>>>>>>> As explained - no.
>>>>>>>
>>>>>>>> If some other build tool would create war archive on the fly, both files
>>>>>>>> could be packaged
>>>>>>>> because there are no constraints on unique file names inside jars/wars
>>>>>>>> and this would be very bad!
>>>>>>> Therefore we want to change the version for the JDBC version4, so we end up
>>>>>>> for those tools with two distinguishable names: commons-dbcp-1.3.jar and
>>>>>>> commons-dbcp-1.4.jar
>>>>>>>
>>>>>>>> Additionally I remember some discussions on Maven lists against
>>>>>>>> relocations (some Apache
>>>>>>>> Commons project changed its groupId to "org.apache.commons", and
>>>>>>>> reverted this change very
>>>>>>>> soon), but I don't remember the exact problem. Maybe you could ask Brett
>>>>>>>> Porter or Jason val Zyl.
>>>>>>> No relocations involved here.
>>>>>>>
>>>>>>>> IMHO the safest and most conservative naming convention would be:
>>>>>>>>
>>>>>>>> commons-dbcp:commons-dbcp:1.4
>>>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>> No, because this would actually make the JDBC4 version available as an
>>>>>>> upgrade for the JDBC3 one. This is the scenario we have to avoid.
>>>>>> I really don't understand this - this is exactly the scenario we want.
>>>>>> Doing it this way DBCP 1.4 will just be an upgrade for DBCP 1.3 with
>>>>>> the additional methods introduced by JDBC 4. How is this any different
>>>>>> from any later version of a component that adds additional methods and
>>>>>> relies on the API of a later version of the JDK?
>>>>> The problem is that it is not backward compatible. You can see this
>>>>> using the test-jar.xml ant build in trunk. Build a jar using JDK
>>>>> 1.6 and then try to build the tests and execute them against this
>>>> I did, with the source/target set to JDK 1.6 - so the minimum JDK for
>>>> DBCP 1.4 is JDK 1.6. That way anyone who wants to depend on DBCP 1.4
>>>> will have to be on JDK 1.6. The mistake IMO is to build DBCP 1.4 using
>>>> JDK 1.6 while setting the source/traget JDK to < JDK 1.6
>>>>
>>> Agreed, but those on 1.4 or 1.5 will still get runtime errors if
>>> they inadvertently get "upgraded" unless I am missing something
>>> here. Running against the 1.4 jar you posted, I now get bad class
>>> file errors.
>>
>> For a project to depend on DBCP 1.4 then they will have to require JDK
>> 1.6. Anyone who depends on that project will also therefore have to
>> require JDK 1.6. I guess its probably possible to have a project built
>> on JDK 1.6, but with a source/target set to a previous JDK and a
>> dependency on DBCP 1.4 - but this is broken since with DBCP 1.4 it
>> will (as you say) only ever run on JDK 1.6.
>>
>> Anyway, this is just a build issue that someone will have to sort out.
>> If that could happen (which tbh I doubt) then they will just have to
>> revert back to DBCP 1.3. This is true of any of our components that
>> have "upgraded" their minimum JDK requirements. In this scenario
>> though its not an issue because we will be providing a DBCP 1.3
>> solution that they can revert to that has all the fixes of DBCP 1.4,
>> just without the JDBC 4 features.
>>
>
> Thanks, Niall. Sorry I was not clear and a little slow to come
> around to seeing the full picture here. I now understand and agree
> with the approach - including not changing the groupId - that you
> have proposed. I have a couple of small things to fix and then I
> will cut RCs for both 1.3 and 1.4.
Great, let me know if theres anything you want me to do to help.
When I created a test branch I added the following step to the ant
build file to update the sources in place:
http://tinyurl.com/ykhafzb
Should we add this to build.xml in trunk?
Niall
> Phil
>
>>> Phil
>>>
>>>
>>>> Niall
>>>>
>>>>> jar using 1.4 or 1.5 and you will get runtime errors. Sebb chased
>>>>>
>>>>> at least one of these down as being due to an import
>>>>> (SQLClientInfoException) in the jdbc4 code.
>>>>>
>>>>> That is the reason I proposed changing the groupId, because I did
>>>>> not want client apps to blow up with runtime errors when "latest
>>>>> version" resolution of range specifiers grab 1.4 for them when they
>>>>> are running jdk 1.4 or 1.5.
>>>>>
>>>>> Phil
>>>>>> Niall
>>>>>>
>>>>>>>> In this situation JDBC4 version always wins. It means you know what
>>>>>>>> version will land in your
>>>>>>>> war file if you have both dependencies in your project and don't specify
>>>>>>>> your preferred version
>>>>>>>> in the pom.xml file.
>>>>>>> No, if you know what you need, you can adjust the groupId for the JDBC4
>>>>>>> version. If your dependencies still contains the other one, you have a
>>>>>>> problem anyway.
>>>>>>>
>>>>>>> - Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Phil Steitz <ph...@gmail.com>.
Niall Pemberton wrote:
> 2009/11/27 Phil Steitz <ph...@gmail.com>:
>> Niall Pemberton wrote:
>>> 2009/11/27 Phil Steitz <ph...@gmail.com>:
>>>> Niall Pemberton wrote:
>>>>> On Fri, Nov 27, 2009 at 8:47 AM, Jörg Schaible <jo...@gmx.de> wrote:
>>>>>> Hi Grzegorz,
>>>>>>
>>>>>> Grzegorz Słowikowski wrote at Freitag, 27. November 2009 09:04:
>>>>>>
>>>>>>> Phil Steitz wrote:
>>>>>>>> Niall Pemberton wrote:
>>>>>>>>
>>>>>>> ...
>>>>>>>> Good points - so what is your recommendation?
>>>>>>>>
>>>>>>>> org.apache.commons:commons-dbcp4:1.3
>>>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>>>
>>>>>>>> or
>>>>>>>>
>>>>>>>> org.apache.commons:commons-dbcp:1.3
>>>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>>>
>>>>>>>> or
>>>>>>>>
>>>>>>>> org.apache.commons:commons-dbcp:1.4
>>>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>>>
>>>>>>>> or?
>>>>>>>>
>>>>>>>>
>>>>>>>> Phil
>>>>>>>>
>>>>>>> ...
>>>>>>> Think about war files, what you will have in WEB-INF/lib. You CANNOT
>>>>>>> have (accidentally,
>>>>>>> from transitive dependencies) commons-dbcp and commond-dbcp4 together in
>>>>>>> the class path,
>>>>>>> so the first proposal is not good.
>>>>>> This can happen for all three proposals. Since the groupId is different
>>>>>> Maven handles the two artifacts in all three cases as unrelated. If the
>>>>>> artifact name for two distinct artifacts clash, it will automatically
>>>>>> prepend the groupId for such cases like the war plugin.
>>>>>>
>>>>>>
>>>>>>> If you release jdbc3 and jdbc4 artifacts from the same release process
>>>>>>> (some code commented for
>>>>>>> jdbc3 version) - this is one release for me, so the version numbers
>>>>>>> should be identical.
>>>>>> Actually we have two incompatible versions. If someone depends (by
>>>>>> transitive deps or directly) on both versions, he has always a problem.
>>>>>> Changing the groupId for one will simply expose the problem more obviously,
>>>>>> because both jars will end up in the dependencies - otherwise Maven version
>>>>>> resolution will silently chose one of them and drop the other one.
>>>>>>
>>>>>>> But I see you will probably prefer releasing separately and creating
>>>>>>> branch for 1.3.x patch releases.
>>>>>>> I would prefer this way too. In this situation we have version 1.3
>>>>>>> backward compatible and version
>>>>>>> 1.4 not compatible. Because incompatibility comes not from your API
>>>>>>> changes but from changes
>>>>>>> inside Java API, then I say you don't have to change version numbering
>>>>>>> to 2.x.x (change on the
>>>>>>> first position).
>>>>>>> I don't remember what's going on inside Maven build of war artifact if
>>>>>>> you have two dependencies
>>>>>>> with different group ids and the same artifact ids. They are different
>>>>>>> artifacts and there is no
>>>>>>> version resolution between them. Maven war plugin prepares war content
>>>>>>> in "target/{artifactId}-{version}" directory before creating war file,
>>>>>>> so one of these files will
>>>>>>> overwrite the other I think.
>>>>>> As explained - no.
>>>>>>
>>>>>>> If some other build tool would create war archive on the fly, both files
>>>>>>> could be packaged
>>>>>>> because there are no constraints on unique file names inside jars/wars
>>>>>>> and this would be very bad!
>>>>>> Therefore we want to change the version for the JDBC version4, so we end up
>>>>>> for those tools with two distinguishable names: commons-dbcp-1.3.jar and
>>>>>> commons-dbcp-1.4.jar
>>>>>>
>>>>>>> Additionally I remember some discussions on Maven lists against
>>>>>>> relocations (some Apache
>>>>>>> Commons project changed its groupId to "org.apache.commons", and
>>>>>>> reverted this change very
>>>>>>> soon), but I don't remember the exact problem. Maybe you could ask Brett
>>>>>>> Porter or Jason val Zyl.
>>>>>> No relocations involved here.
>>>>>>
>>>>>>> IMHO the safest and most conservative naming convention would be:
>>>>>>>
>>>>>>> commons-dbcp:commons-dbcp:1.4
>>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>> No, because this would actually make the JDBC4 version available as an
>>>>>> upgrade for the JDBC3 one. This is the scenario we have to avoid.
>>>>> I really don't understand this - this is exactly the scenario we want.
>>>>> Doing it this way DBCP 1.4 will just be an upgrade for DBCP 1.3 with
>>>>> the additional methods introduced by JDBC 4. How is this any different
>>>>> from any later version of a component that adds additional methods and
>>>>> relies on the API of a later version of the JDK?
>>>> The problem is that it is not backward compatible. You can see this
>>>> using the test-jar.xml ant build in trunk. Build a jar using JDK
>>>> 1.6 and then try to build the tests and execute them against this
>>> I did, with the source/target set to JDK 1.6 - so the minimum JDK for
>>> DBCP 1.4 is JDK 1.6. That way anyone who wants to depend on DBCP 1.4
>>> will have to be on JDK 1.6. The mistake IMO is to build DBCP 1.4 using
>>> JDK 1.6 while setting the source/traget JDK to < JDK 1.6
>>>
>> Agreed, but those on 1.4 or 1.5 will still get runtime errors if
>> they inadvertently get "upgraded" unless I am missing something
>> here. Running against the 1.4 jar you posted, I now get bad class
>> file errors.
>
> For a project to depend on DBCP 1.4 then they will have to require JDK
> 1.6. Anyone who depends on that project will also therefore have to
> require JDK 1.6. I guess its probably possible to have a project built
> on JDK 1.6, but with a source/target set to a previous JDK and a
> dependency on DBCP 1.4 - but this is broken since with DBCP 1.4 it
> will (as you say) only ever run on JDK 1.6.
>
> Anyway, this is just a build issue that someone will have to sort out.
> If that could happen (which tbh I doubt) then they will just have to
> revert back to DBCP 1.3. This is true of any of our components that
> have "upgraded" their minimum JDK requirements. In this scenario
> though its not an issue because we will be providing a DBCP 1.3
> solution that they can revert to that has all the fixes of DBCP 1.4,
> just without the JDBC 4 features.
>
Thanks, Niall. Sorry I was not clear and a little slow to come
around to seeing the full picture here. I now understand and agree
with the approach - including not changing the groupId - that you
have proposed. I have a couple of small things to fix and then I
will cut RCs for both 1.3 and 1.4.
Phil
>> Phil
>>
>>
>>> Niall
>>>
>>>> jar using 1.4 or 1.5 and you will get runtime errors. Sebb chased
>>>>
>>>> at least one of these down as being due to an import
>>>> (SQLClientInfoException) in the jdbc4 code.
>>>>
>>>> That is the reason I proposed changing the groupId, because I did
>>>> not want client apps to blow up with runtime errors when "latest
>>>> version" resolution of range specifiers grab 1.4 for them when they
>>>> are running jdk 1.4 or 1.5.
>>>>
>>>> Phil
>>>>> Niall
>>>>>
>>>>>>> In this situation JDBC4 version always wins. It means you know what
>>>>>>> version will land in your
>>>>>>> war file if you have both dependencies in your project and don't specify
>>>>>>> your preferred version
>>>>>>> in the pom.xml file.
>>>>>> No, if you know what you need, you can adjust the groupId for the JDBC4
>>>>>> version. If your dependencies still contains the other one, you have a
>>>>>> problem anyway.
>>>>>>
>>>>>> - Jörg
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Niall Pemberton <ni...@gmail.com>.
2009/11/27 Phil Steitz <ph...@gmail.com>:
> Niall Pemberton wrote:
>> 2009/11/27 Phil Steitz <ph...@gmail.com>:
>>> Niall Pemberton wrote:
>>>> On Fri, Nov 27, 2009 at 8:47 AM, Jörg Schaible <jo...@gmx.de> wrote:
>>>>> Hi Grzegorz,
>>>>>
>>>>> Grzegorz Słowikowski wrote at Freitag, 27. November 2009 09:04:
>>>>>
>>>>>> Phil Steitz wrote:
>>>>>>> Niall Pemberton wrote:
>>>>>>>
>>>>>> ...
>>>>>>> Good points - so what is your recommendation?
>>>>>>>
>>>>>>> org.apache.commons:commons-dbcp4:1.3
>>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>>
>>>>>>> or
>>>>>>>
>>>>>>> org.apache.commons:commons-dbcp:1.3
>>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>>
>>>>>>> or
>>>>>>>
>>>>>>> org.apache.commons:commons-dbcp:1.4
>>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>>
>>>>>>> or?
>>>>>>>
>>>>>>>
>>>>>>> Phil
>>>>>>>
>>>>>> ...
>>>>>> Think about war files, what you will have in WEB-INF/lib. You CANNOT
>>>>>> have (accidentally,
>>>>>> from transitive dependencies) commons-dbcp and commond-dbcp4 together in
>>>>>> the class path,
>>>>>> so the first proposal is not good.
>>>>> This can happen for all three proposals. Since the groupId is different
>>>>> Maven handles the two artifacts in all three cases as unrelated. If the
>>>>> artifact name for two distinct artifacts clash, it will automatically
>>>>> prepend the groupId for such cases like the war plugin.
>>>>>
>>>>>
>>>>>> If you release jdbc3 and jdbc4 artifacts from the same release process
>>>>>> (some code commented for
>>>>>> jdbc3 version) - this is one release for me, so the version numbers
>>>>>> should be identical.
>>>>> Actually we have two incompatible versions. If someone depends (by
>>>>> transitive deps or directly) on both versions, he has always a problem.
>>>>> Changing the groupId for one will simply expose the problem more obviously,
>>>>> because both jars will end up in the dependencies - otherwise Maven version
>>>>> resolution will silently chose one of them and drop the other one.
>>>>>
>>>>>> But I see you will probably prefer releasing separately and creating
>>>>>> branch for 1.3.x patch releases.
>>>>>> I would prefer this way too. In this situation we have version 1.3
>>>>>> backward compatible and version
>>>>>> 1.4 not compatible. Because incompatibility comes not from your API
>>>>>> changes but from changes
>>>>>> inside Java API, then I say you don't have to change version numbering
>>>>>> to 2.x.x (change on the
>>>>>> first position).
>>>>>> I don't remember what's going on inside Maven build of war artifact if
>>>>>> you have two dependencies
>>>>>> with different group ids and the same artifact ids. They are different
>>>>>> artifacts and there is no
>>>>>> version resolution between them. Maven war plugin prepares war content
>>>>>> in "target/{artifactId}-{version}" directory before creating war file,
>>>>>> so one of these files will
>>>>>> overwrite the other I think.
>>>>> As explained - no.
>>>>>
>>>>>> If some other build tool would create war archive on the fly, both files
>>>>>> could be packaged
>>>>>> because there are no constraints on unique file names inside jars/wars
>>>>>> and this would be very bad!
>>>>> Therefore we want to change the version for the JDBC version4, so we end up
>>>>> for those tools with two distinguishable names: commons-dbcp-1.3.jar and
>>>>> commons-dbcp-1.4.jar
>>>>>
>>>>>> Additionally I remember some discussions on Maven lists against
>>>>>> relocations (some Apache
>>>>>> Commons project changed its groupId to "org.apache.commons", and
>>>>>> reverted this change very
>>>>>> soon), but I don't remember the exact problem. Maybe you could ask Brett
>>>>>> Porter or Jason val Zyl.
>>>>> No relocations involved here.
>>>>>
>>>>>> IMHO the safest and most conservative naming convention would be:
>>>>>>
>>>>>> commons-dbcp:commons-dbcp:1.4
>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>> No, because this would actually make the JDBC4 version available as an
>>>>> upgrade for the JDBC3 one. This is the scenario we have to avoid.
>>>> I really don't understand this - this is exactly the scenario we want.
>>>> Doing it this way DBCP 1.4 will just be an upgrade for DBCP 1.3 with
>>>> the additional methods introduced by JDBC 4. How is this any different
>>>> from any later version of a component that adds additional methods and
>>>> relies on the API of a later version of the JDK?
>>> The problem is that it is not backward compatible. You can see this
>>> using the test-jar.xml ant build in trunk. Build a jar using JDK
>>> 1.6 and then try to build the tests and execute them against this
>>
>> I did, with the source/target set to JDK 1.6 - so the minimum JDK for
>> DBCP 1.4 is JDK 1.6. That way anyone who wants to depend on DBCP 1.4
>> will have to be on JDK 1.6. The mistake IMO is to build DBCP 1.4 using
>> JDK 1.6 while setting the source/traget JDK to < JDK 1.6
>>
>
> Agreed, but those on 1.4 or 1.5 will still get runtime errors if
> they inadvertently get "upgraded" unless I am missing something
> here. Running against the 1.4 jar you posted, I now get bad class
> file errors.
For a project to depend on DBCP 1.4 then they will have to require JDK
1.6. Anyone who depends on that project will also therefore have to
require JDK 1.6. I guess its probably possible to have a project built
on JDK 1.6, but with a source/target set to a previous JDK and a
dependency on DBCP 1.4 - but this is broken since with DBCP 1.4 it
will (as you say) only ever run on JDK 1.6.
Anyway, this is just a build issue that someone will have to sort out.
If that could happen (which tbh I doubt) then they will just have to
revert back to DBCP 1.3. This is true of any of our components that
have "upgraded" their minimum JDK requirements. In this scenario
though its not an issue because we will be providing a DBCP 1.3
solution that they can revert to that has all the fixes of DBCP 1.4,
just without the JDBC 4 features.
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: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Phil Steitz <ph...@gmail.com>.
Niall Pemberton wrote:
> On Fri, Nov 27, 2009 at 10:45 AM, Jörg Schaible <jo...@gmx.de> 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: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Niall Pemberton <ni...@gmail.com>.
On Fri, Nov 27, 2009 at 10:45 AM, Jörg Schaible <jo...@gmx.de> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Phil Steitz <ph...@gmail.com>.
Niall Pemberton wrote:
> 2009/11/27 Phil Steitz <ph...@gmail.com>:
>> Niall Pemberton wrote:
>>> On Fri, Nov 27, 2009 at 8:47 AM, Jörg Schaible <jo...@gmx.de> wrote:
>>>> Hi Grzegorz,
>>>>
>>>> Grzegorz Słowikowski wrote at Freitag, 27. November 2009 09:04:
>>>>
>>>>> Phil Steitz wrote:
>>>>>> Niall Pemberton wrote:
>>>>>>
>>>>> ...
>>>>>> Good points - so what is your recommendation?
>>>>>>
>>>>>> org.apache.commons:commons-dbcp4:1.3
>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>
>>>>>> or
>>>>>>
>>>>>> org.apache.commons:commons-dbcp:1.3
>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>
>>>>>> or
>>>>>>
>>>>>> org.apache.commons:commons-dbcp:1.4
>>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>>
>>>>>> or?
>>>>>>
>>>>>>
>>>>>> Phil
>>>>>>
>>>>> ...
>>>>> Think about war files, what you will have in WEB-INF/lib. You CANNOT
>>>>> have (accidentally,
>>>>> from transitive dependencies) commons-dbcp and commond-dbcp4 together in
>>>>> the class path,
>>>>> so the first proposal is not good.
>>>> This can happen for all three proposals. Since the groupId is different
>>>> Maven handles the two artifacts in all three cases as unrelated. If the
>>>> artifact name for two distinct artifacts clash, it will automatically
>>>> prepend the groupId for such cases like the war plugin.
>>>>
>>>>
>>>>> If you release jdbc3 and jdbc4 artifacts from the same release process
>>>>> (some code commented for
>>>>> jdbc3 version) - this is one release for me, so the version numbers
>>>>> should be identical.
>>>> Actually we have two incompatible versions. If someone depends (by
>>>> transitive deps or directly) on both versions, he has always a problem.
>>>> Changing the groupId for one will simply expose the problem more obviously,
>>>> because both jars will end up in the dependencies - otherwise Maven version
>>>> resolution will silently chose one of them and drop the other one.
>>>>
>>>>> But I see you will probably prefer releasing separately and creating
>>>>> branch for 1.3.x patch releases.
>>>>> I would prefer this way too. In this situation we have version 1.3
>>>>> backward compatible and version
>>>>> 1.4 not compatible. Because incompatibility comes not from your API
>>>>> changes but from changes
>>>>> inside Java API, then I say you don't have to change version numbering
>>>>> to 2.x.x (change on the
>>>>> first position).
>>>>> I don't remember what's going on inside Maven build of war artifact if
>>>>> you have two dependencies
>>>>> with different group ids and the same artifact ids. They are different
>>>>> artifacts and there is no
>>>>> version resolution between them. Maven war plugin prepares war content
>>>>> in "target/{artifactId}-{version}" directory before creating war file,
>>>>> so one of these files will
>>>>> overwrite the other I think.
>>>> As explained - no.
>>>>
>>>>> If some other build tool would create war archive on the fly, both files
>>>>> could be packaged
>>>>> because there are no constraints on unique file names inside jars/wars
>>>>> and this would be very bad!
>>>> Therefore we want to change the version for the JDBC version4, so we end up
>>>> for those tools with two distinguishable names: commons-dbcp-1.3.jar and
>>>> commons-dbcp-1.4.jar
>>>>
>>>>> Additionally I remember some discussions on Maven lists against
>>>>> relocations (some Apache
>>>>> Commons project changed its groupId to "org.apache.commons", and
>>>>> reverted this change very
>>>>> soon), but I don't remember the exact problem. Maybe you could ask Brett
>>>>> Porter or Jason val Zyl.
>>>> No relocations involved here.
>>>>
>>>>> IMHO the safest and most conservative naming convention would be:
>>>>>
>>>>> commons-dbcp:commons-dbcp:1.4
>>>>> commons-dbcp:commons-dbcp:1.3
>>>> No, because this would actually make the JDBC4 version available as an
>>>> upgrade for the JDBC3 one. This is the scenario we have to avoid.
>>> I really don't understand this - this is exactly the scenario we want.
>>> Doing it this way DBCP 1.4 will just be an upgrade for DBCP 1.3 with
>>> the additional methods introduced by JDBC 4. How is this any different
>>> from any later version of a component that adds additional methods and
>>> relies on the API of a later version of the JDK?
>> The problem is that it is not backward compatible. You can see this
>> using the test-jar.xml ant build in trunk. Build a jar using JDK
>> 1.6 and then try to build the tests and execute them against this
>
> I did, with the source/target set to JDK 1.6 - so the minimum JDK for
> DBCP 1.4 is JDK 1.6. That way anyone who wants to depend on DBCP 1.4
> will have to be on JDK 1.6. The mistake IMO is to build DBCP 1.4 using
> JDK 1.6 while setting the source/traget JDK to < JDK 1.6
>
Agreed, but those on 1.4 or 1.5 will still get runtime errors if
they inadvertently get "upgraded" unless I am missing something
here. Running against the 1.4 jar you posted, I now get bad class
file errors.
Phil
> Niall
>
>> jar using 1.4 or 1.5 and you will get runtime errors. Sebb chased
>>
>> at least one of these down as being due to an import
>> (SQLClientInfoException) in the jdbc4 code.
>>
>> That is the reason I proposed changing the groupId, because I did
>> not want client apps to blow up with runtime errors when "latest
>> version" resolution of range specifiers grab 1.4 for them when they
>> are running jdk 1.4 or 1.5.
>>
>> Phil
>>> Niall
>>>
>>>>> In this situation JDBC4 version always wins. It means you know what
>>>>> version will land in your
>>>>> war file if you have both dependencies in your project and don't specify
>>>>> your preferred version
>>>>> in the pom.xml file.
>>>> No, if you know what you need, you can adjust the groupId for the JDBC4
>>>> version. If your dependencies still contains the other one, you have a
>>>> problem anyway.
>>>>
>>>> - Jörg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Niall Pemberton <ni...@gmail.com>.
2009/11/27 Phil Steitz <ph...@gmail.com>:
> Niall Pemberton wrote:
>> On Fri, Nov 27, 2009 at 8:47 AM, Jörg Schaible <jo...@gmx.de> wrote:
>>> Hi Grzegorz,
>>>
>>> Grzegorz Słowikowski wrote at Freitag, 27. November 2009 09:04:
>>>
>>>>
>>>> Phil Steitz wrote:
>>>>> Niall Pemberton wrote:
>>>>>
>>>> ...
>>>>> Good points - so what is your recommendation?
>>>>>
>>>>> org.apache.commons:commons-dbcp4:1.3
>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>
>>>>> or
>>>>>
>>>>> org.apache.commons:commons-dbcp:1.3
>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>
>>>>> or
>>>>>
>>>>> org.apache.commons:commons-dbcp:1.4
>>>>> commons-dbcp:commons-dbcp:1.3
>>>>>
>>>>> or?
>>>>>
>>>>>
>>>>> Phil
>>>>>
>>>> ...
>>>> Think about war files, what you will have in WEB-INF/lib. You CANNOT
>>>> have (accidentally,
>>>> from transitive dependencies) commons-dbcp and commond-dbcp4 together in
>>>> the class path,
>>>> so the first proposal is not good.
>>> This can happen for all three proposals. Since the groupId is different
>>> Maven handles the two artifacts in all three cases as unrelated. If the
>>> artifact name for two distinct artifacts clash, it will automatically
>>> prepend the groupId for such cases like the war plugin.
>>>
>>>
>>>> If you release jdbc3 and jdbc4 artifacts from the same release process
>>>> (some code commented for
>>>> jdbc3 version) - this is one release for me, so the version numbers
>>>> should be identical.
>>> Actually we have two incompatible versions. If someone depends (by
>>> transitive deps or directly) on both versions, he has always a problem.
>>> Changing the groupId for one will simply expose the problem more obviously,
>>> because both jars will end up in the dependencies - otherwise Maven version
>>> resolution will silently chose one of them and drop the other one.
>>>
>>>> But I see you will probably prefer releasing separately and creating
>>>> branch for 1.3.x patch releases.
>>>> I would prefer this way too. In this situation we have version 1.3
>>>> backward compatible and version
>>>> 1.4 not compatible. Because incompatibility comes not from your API
>>>> changes but from changes
>>>> inside Java API, then I say you don't have to change version numbering
>>>> to 2.x.x (change on the
>>>> first position).
>>>> I don't remember what's going on inside Maven build of war artifact if
>>>> you have two dependencies
>>>> with different group ids and the same artifact ids. They are different
>>>> artifacts and there is no
>>>> version resolution between them. Maven war plugin prepares war content
>>>> in "target/{artifactId}-{version}" directory before creating war file,
>>>> so one of these files will
>>>> overwrite the other I think.
>>> As explained - no.
>>>
>>>> If some other build tool would create war archive on the fly, both files
>>>> could be packaged
>>>> because there are no constraints on unique file names inside jars/wars
>>>> and this would be very bad!
>>> Therefore we want to change the version for the JDBC version4, so we end up
>>> for those tools with two distinguishable names: commons-dbcp-1.3.jar and
>>> commons-dbcp-1.4.jar
>>>
>>>> Additionally I remember some discussions on Maven lists against
>>>> relocations (some Apache
>>>> Commons project changed its groupId to "org.apache.commons", and
>>>> reverted this change very
>>>> soon), but I don't remember the exact problem. Maybe you could ask Brett
>>>> Porter or Jason val Zyl.
>>> No relocations involved here.
>>>
>>>> IMHO the safest and most conservative naming convention would be:
>>>>
>>>> commons-dbcp:commons-dbcp:1.4
>>>> commons-dbcp:commons-dbcp:1.3
>>> No, because this would actually make the JDBC4 version available as an
>>> upgrade for the JDBC3 one. This is the scenario we have to avoid.
>>
>> I really don't understand this - this is exactly the scenario we want.
>> Doing it this way DBCP 1.4 will just be an upgrade for DBCP 1.3 with
>> the additional methods introduced by JDBC 4. How is this any different
>> from any later version of a component that adds additional methods and
>> relies on the API of a later version of the JDK?
>
> The problem is that it is not backward compatible. You can see this
> using the test-jar.xml ant build in trunk. Build a jar using JDK
> 1.6 and then try to build the tests and execute them against this
I did, with the source/target set to JDK 1.6 - so the minimum JDK for
DBCP 1.4 is JDK 1.6. That way anyone who wants to depend on DBCP 1.4
will have to be on JDK 1.6. The mistake IMO is to build DBCP 1.4 using
JDK 1.6 while setting the source/traget JDK to < JDK 1.6
Niall
> jar using 1.4 or 1.5 and you will get runtime errors. Sebb chased
>
> at least one of these down as being due to an import
> (SQLClientInfoException) in the jdbc4 code.
>
> That is the reason I proposed changing the groupId, because I did
> not want client apps to blow up with runtime errors when "latest
> version" resolution of range specifiers grab 1.4 for them when they
> are running jdk 1.4 or 1.5.
>
> Phil
>>
>> Niall
>>
>>>> In this situation JDBC4 version always wins. It means you know what
>>>> version will land in your
>>>> war file if you have both dependencies in your project and don't specify
>>>> your preferred version
>>>> in the pom.xml file.
>>> No, if you know what you need, you can adjust the groupId for the JDBC4
>>> version. If your dependencies still contains the other one, you have a
>>> problem anyway.
>>>
>>> - Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Phil Steitz <ph...@gmail.com>.
Niall Pemberton wrote:
> On Fri, Nov 27, 2009 at 8:47 AM, Jörg Schaible <jo...@gmx.de> wrote:
>> Hi Grzegorz,
>>
>> Grzegorz Słowikowski wrote at Freitag, 27. November 2009 09:04:
>>
>>>
>>> Phil Steitz wrote:
>>>> Niall Pemberton wrote:
>>>>
>>> ...
>>>> Good points - so what is your recommendation?
>>>>
>>>> org.apache.commons:commons-dbcp4:1.3
>>>> commons-dbcp:commons-dbcp:1.3
>>>>
>>>> or
>>>>
>>>> org.apache.commons:commons-dbcp:1.3
>>>> commons-dbcp:commons-dbcp:1.3
>>>>
>>>> or
>>>>
>>>> org.apache.commons:commons-dbcp:1.4
>>>> commons-dbcp:commons-dbcp:1.3
>>>>
>>>> or?
>>>>
>>>>
>>>> Phil
>>>>
>>> ...
>>> Think about war files, what you will have in WEB-INF/lib. You CANNOT
>>> have (accidentally,
>>> from transitive dependencies) commons-dbcp and commond-dbcp4 together in
>>> the class path,
>>> so the first proposal is not good.
>> This can happen for all three proposals. Since the groupId is different
>> Maven handles the two artifacts in all three cases as unrelated. If the
>> artifact name for two distinct artifacts clash, it will automatically
>> prepend the groupId for such cases like the war plugin.
>>
>>
>>> If you release jdbc3 and jdbc4 artifacts from the same release process
>>> (some code commented for
>>> jdbc3 version) - this is one release for me, so the version numbers
>>> should be identical.
>> Actually we have two incompatible versions. If someone depends (by
>> transitive deps or directly) on both versions, he has always a problem.
>> Changing the groupId for one will simply expose the problem more obviously,
>> because both jars will end up in the dependencies - otherwise Maven version
>> resolution will silently chose one of them and drop the other one.
>>
>>> But I see you will probably prefer releasing separately and creating
>>> branch for 1.3.x patch releases.
>>> I would prefer this way too. In this situation we have version 1.3
>>> backward compatible and version
>>> 1.4 not compatible. Because incompatibility comes not from your API
>>> changes but from changes
>>> inside Java API, then I say you don't have to change version numbering
>>> to 2.x.x (change on the
>>> first position).
>>> I don't remember what's going on inside Maven build of war artifact if
>>> you have two dependencies
>>> with different group ids and the same artifact ids. They are different
>>> artifacts and there is no
>>> version resolution between them. Maven war plugin prepares war content
>>> in "target/{artifactId}-{version}" directory before creating war file,
>>> so one of these files will
>>> overwrite the other I think.
>> As explained - no.
>>
>>> If some other build tool would create war archive on the fly, both files
>>> could be packaged
>>> because there are no constraints on unique file names inside jars/wars
>>> and this would be very bad!
>> Therefore we want to change the version for the JDBC version4, so we end up
>> for those tools with two distinguishable names: commons-dbcp-1.3.jar and
>> commons-dbcp-1.4.jar
>>
>>> Additionally I remember some discussions on Maven lists against
>>> relocations (some Apache
>>> Commons project changed its groupId to "org.apache.commons", and
>>> reverted this change very
>>> soon), but I don't remember the exact problem. Maybe you could ask Brett
>>> Porter or Jason val Zyl.
>> No relocations involved here.
>>
>>> IMHO the safest and most conservative naming convention would be:
>>>
>>> commons-dbcp:commons-dbcp:1.4
>>> commons-dbcp:commons-dbcp:1.3
>> No, because this would actually make the JDBC4 version available as an
>> upgrade for the JDBC3 one. This is the scenario we have to avoid.
>
> I really don't understand this - this is exactly the scenario we want.
> Doing it this way DBCP 1.4 will just be an upgrade for DBCP 1.3 with
> the additional methods introduced by JDBC 4. How is this any different
> from any later version of a component that adds additional methods and
> relies on the API of a later version of the JDK?
The problem is that it is not backward compatible. You can see this
using the test-jar.xml ant build in trunk. Build a jar using JDK
1.6 and then try to build the tests and execute them against this
jar using 1.4 or 1.5 and you will get runtime errors. Sebb chased
at least one of these down as being due to an import
(SQLClientInfoException) in the jdbc4 code.
That is the reason I proposed changing the groupId, because I did
not want client apps to blow up with runtime errors when "latest
version" resolution of range specifiers grab 1.4 for them when they
are running jdk 1.4 or 1.5.
Phil
>
> Niall
>
>>> In this situation JDBC4 version always wins. It means you know what
>>> version will land in your
>>> war file if you have both dependencies in your project and don't specify
>>> your preferred version
>>> in the pom.xml file.
>> No, if you know what you need, you can adjust the groupId for the JDBC4
>> version. If your dependencies still contains the other one, you have a
>> problem anyway.
>>
>> - Jörg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Niall Pemberton <ni...@gmail.com>.
On Fri, Nov 27, 2009 at 8:47 AM, Jörg Schaible <jo...@gmx.de> wrote:
> Hi Grzegorz,
>
> Grzegorz Słowikowski wrote at Freitag, 27. November 2009 09:04:
>
>>
>>
>> Phil Steitz wrote:
>>> Niall Pemberton wrote:
>>>
>> ...
>>> Good points - so what is your recommendation?
>>>
>>> org.apache.commons:commons-dbcp4:1.3
>>> commons-dbcp:commons-dbcp:1.3
>>>
>>> or
>>>
>>> org.apache.commons:commons-dbcp:1.3
>>> commons-dbcp:commons-dbcp:1.3
>>>
>>> or
>>>
>>> org.apache.commons:commons-dbcp:1.4
>>> commons-dbcp:commons-dbcp:1.3
>>>
>>> or?
>>>
>>>
>>> Phil
>>>
>> ...
>> Think about war files, what you will have in WEB-INF/lib. You CANNOT
>> have (accidentally,
>> from transitive dependencies) commons-dbcp and commond-dbcp4 together in
>> the class path,
>> so the first proposal is not good.
>
> This can happen for all three proposals. Since the groupId is different
> Maven handles the two artifacts in all three cases as unrelated. If the
> artifact name for two distinct artifacts clash, it will automatically
> prepend the groupId for such cases like the war plugin.
>
>
>> If you release jdbc3 and jdbc4 artifacts from the same release process
>> (some code commented for
>> jdbc3 version) - this is one release for me, so the version numbers
>> should be identical.
>
> Actually we have two incompatible versions. If someone depends (by
> transitive deps or directly) on both versions, he has always a problem.
> Changing the groupId for one will simply expose the problem more obviously,
> because both jars will end up in the dependencies - otherwise Maven version
> resolution will silently chose one of them and drop the other one.
>
>> But I see you will probably prefer releasing separately and creating
>> branch for 1.3.x patch releases.
>> I would prefer this way too. In this situation we have version 1.3
>> backward compatible and version
>> 1.4 not compatible. Because incompatibility comes not from your API
>> changes but from changes
>> inside Java API, then I say you don't have to change version numbering
>> to 2.x.x (change on the
>> first position).
>> I don't remember what's going on inside Maven build of war artifact if
>> you have two dependencies
>> with different group ids and the same artifact ids. They are different
>> artifacts and there is no
>> version resolution between them. Maven war plugin prepares war content
>> in "target/{artifactId}-{version}" directory before creating war file,
>> so one of these files will
>> overwrite the other I think.
>
> As explained - no.
>
>> If some other build tool would create war archive on the fly, both files
>> could be packaged
>> because there are no constraints on unique file names inside jars/wars
>> and this would be very bad!
>
> Therefore we want to change the version for the JDBC version4, so we end up
> for those tools with two distinguishable names: commons-dbcp-1.3.jar and
> commons-dbcp-1.4.jar
>
>> Additionally I remember some discussions on Maven lists against
>> relocations (some Apache
>> Commons project changed its groupId to "org.apache.commons", and
>> reverted this change very
>> soon), but I don't remember the exact problem. Maybe you could ask Brett
>> Porter or Jason val Zyl.
>
> No relocations involved here.
>
>> IMHO the safest and most conservative naming convention would be:
>>
>> commons-dbcp:commons-dbcp:1.4
>> commons-dbcp:commons-dbcp:1.3
>
> No, because this would actually make the JDBC4 version available as an
> upgrade for the JDBC3 one. This is the scenario we have to avoid.
I really don't understand this - this is exactly the scenario we want.
Doing it this way DBCP 1.4 will just be an upgrade for DBCP 1.3 with
the additional methods introduced by JDBC 4. How is this any different
from any later version of a component that adds additional methods and
relies on the API of a later version of the JDK?
Niall
>> In this situation JDBC4 version always wins. It means you know what
>> version will land in your
>> war file if you have both dependencies in your project and don't specify
>> your preferred version
>> in the pom.xml file.
>
> No, if you know what you need, you can adjust the groupId for the JDBC4
> version. If your dependencies still contains the other one, you have a
> problem anyway.
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Jörg Schaible <jo...@gmx.de>.
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Grzegorz Słowikowski <gs...@gmail.com>.
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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Jörg Schaible <jo...@gmx.de>.
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Grzegorz Słowikowski <gs...@gmail.com>.
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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Jörg Schaible <jo...@gmx.de>.
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Paul Benedict <pb...@apache.org>.
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 <ph...@gmail.com> wrote:
> Niall Pemberton wrote:
>> On Thu, Nov 26, 2009 at 4:39 PM, Phil Steitz <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Phil Steitz <ph...@gmail.com>.
Niall Pemberton wrote:
> On Thu, Nov 26, 2009 at 4:39 PM, Phil Steitz <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Niall Pemberton <ni...@gmail.com>.
On Thu, Nov 26, 2009 at 4:39 PM, Phil Steitz <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Jörg Schaible <jo...@gmx.de>.
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Phil Steitz <ph...@gmail.com>.
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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Jörg Schaible <jo...@gmx.de>.
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Phil Steitz <ph...@gmail.com>.
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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Jörg Schaible <jo...@gmx.de>.
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Phil Steitz <ph...@gmail.com>.
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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Jörg Schaible <jo...@gmx.de>.
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Paul Benedict <pb...@apache.org>.
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.
Paul
On Wed, Nov 25, 2009 at 6:51 PM, Niall Pemberton
<ni...@gmail.com> wrote:
> On Thu, Nov 26, 2009 at 12:46 AM, Paul Benedict <pb...@apache.org> 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 <ph...@gmail.com> wrote:
>>> Niall Pemberton wrote:
>>>> On Wed, Nov 25, 2009 at 11:39 PM, Niall Pemberton
>>>> <ni...@gmail.com> wrote:
>>>>> On Wed, Nov 25, 2009 at 11:31 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>>> Niall Pemberton wrote:
>>>>>>> On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict <pb...@apache.org> 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 <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Paul Benedict <pb...@apache.org>.
Niall,
Since the "sources" and "javadocs" are qualifiers, I am concerned
there is an incompatibility here. I can't prove it, but I suspect
there might be.
Paul
On Wed, Nov 25, 2009 at 6:51 PM, Niall Pemberton
<ni...@gmail.com> wrote:
> On Thu, Nov 26, 2009 at 12:46 AM, Paul Benedict <pb...@apache.org> 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 <ph...@gmail.com> wrote:
>>> Niall Pemberton wrote:
>>>> On Wed, Nov 25, 2009 at 11:39 PM, Niall Pemberton
>>>> <ni...@gmail.com> wrote:
>>>>> On Wed, Nov 25, 2009 at 11:31 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>>> Niall Pemberton wrote:
>>>>>>> On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict <pb...@apache.org> 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 <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Niall Pemberton <ni...@gmail.com>.
On Thu, Nov 26, 2009 at 12:46 AM, Paul Benedict <pb...@apache.org> 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 <ph...@gmail.com> wrote:
>> Niall Pemberton wrote:
>>> On Wed, Nov 25, 2009 at 11:39 PM, Niall Pemberton
>>> <ni...@gmail.com> wrote:
>>>> On Wed, Nov 25, 2009 at 11:31 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>> Niall Pemberton wrote:
>>>>>> On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict <pb...@apache.org> 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 <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Paul Benedict <pb...@apache.org>.
Does adding a classifier like "jdbc3" affect the creation of the
-source and -javadoc classifiers?
On Wed, Nov 25, 2009 at 6:06 PM, Phil Steitz <ph...@gmail.com> wrote:
> Niall Pemberton wrote:
>> On Wed, Nov 25, 2009 at 11:39 PM, Niall Pemberton
>> <ni...@gmail.com> wrote:
>>> On Wed, Nov 25, 2009 at 11:31 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>> Niall Pemberton wrote:
>>>>> On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict <pb...@apache.org> 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 <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Phil Steitz <ph...@gmail.com>.
Niall Pemberton wrote:
> On Wed, Nov 25, 2009 at 11:39 PM, Niall Pemberton
> <ni...@gmail.com> wrote:
>> On Wed, Nov 25, 2009 at 11:31 PM, Phil Steitz <ph...@gmail.com> wrote:
>>> Niall Pemberton wrote:
>>>> On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict <pb...@apache.org> 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 <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Nov 25, 2009 at 11:39 PM, Niall Pemberton
<ni...@gmail.com> wrote:
> On Wed, Nov 25, 2009 at 11:31 PM, Phil Steitz <ph...@gmail.com> wrote:
>> Niall Pemberton wrote:
>>> On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict <pb...@apache.org> 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
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 <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Nov 25, 2009 at 11:31 PM, Phil Steitz <ph...@gmail.com> wrote:
> Niall Pemberton wrote:
>> On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict <pb...@apache.org> 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
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 <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Phil Steitz <ph...@gmail.com>.
Niall Pemberton wrote:
> On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict <pb...@apache.org> 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.
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 <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Paul Benedict <pb...@apache.org>.
I think Niall has good counterpoints. I think his point is summed up with:
* Keep same groupId
* Keep same artifactId
* Keep same version
* Different classifiers are appropriate.
If so, I am +1 with it.
Paul
On Wed, Nov 25, 2009 at 5:25 PM, Niall Pemberton
<ni...@gmail.com> wrote:
> On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict <pb...@apache.org> 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.
>
> 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 <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict <pb...@apache.org> 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.
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 <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Paul Benedict <pb...@apache.org>.
Correction:
For users who use employ version ranges in their POMs like "[1.3,)"
they are telling Maven they want >= 1.3. It is misleading -- I
actually believe wrong -- to say that the "1.3-jdbc3" version is a
greater version than
than version "1.3".
Paul
On Wed, Nov 25, 2009 at 5:05 PM, Paul Benedict <pb...@apache.org> wrote:
> Brent,
>
> If you haven't read the Sonatype link, it tells some important things
> about how the version number is interpreted by Maven. The standard is
> using 3 numbers, and it allows Maven to know that, for example, 1.3 <
> 1.4. But what happens if you version as "1.3-jdbc3"? Is anyone going
> to confident in that 1.3 < 1.3-jdbc3? It's not a version number, but
> clearly a different artifact. As the link says, Maven treats
> non-standard version numbers as straight lexical comparisons.
>
> For users who use employ version ranges in their POMs like "[1,3,)"
> they are telling Maven they want >= 1.3. It is misleading -- I
> actually believe wrong -- to say that the "1.3-jdbc3" version is less
> than version "1.3".
>
> I think it's clear you have separate artifacts because the "1.3-jdbc3"
> incorrectly fit on the range of version numbers.
>
> Paul
>
> On Wed, Nov 25, 2009 at 4:56 PM, Brent Worden <br...@gmail.com> wrote:
>> On Wed, Nov 25, 2009 at 4:23 PM, Paul Benedict <pb...@apache.org> 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
>>>
>>> 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
>>>
>>
>> I do not agree with the artifact/version statements. In my mind,
>> different artifactId's imply the jars are companion or supplementary
>> artifacts. The JDBC 3 and 4 version of commons-dbcp are drop in
>> replacements of each other. To me, this implies different artifact
>> versions.
>>
>> I do agree, that the groupId should be constant.
>>
>> Also, if the multiple version approach is taken, I would explicitly
>> call out the JDBC version in all artifacts in order to be consistent
>> and eliminate user ambiguity.
>>
>> Brent
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Paul Benedict <pb...@apache.org>.
Brent,
If you haven't read the Sonatype link, it tells some important things
about how the version number is interpreted by Maven. The standard is
using 3 numbers, and it allows Maven to know that, for example, 1.3 <
1.4. But what happens if you version as "1.3-jdbc3"? Is anyone going
to confident in that 1.3 < 1.3-jdbc3? It's not a version number, but
clearly a different artifact. As the link says, Maven treats
non-standard version numbers as straight lexical comparisons.
For users who use employ version ranges in their POMs like "[1,3,)"
they are telling Maven they want >= 1.3. It is misleading -- I
actually believe wrong -- to say that the "1.3-jdbc3" version is less
than version "1.3".
I think it's clear you have separate artifacts because the "1.3-jdbc3"
incorrectly fit on the range of version numbers.
Paul
On Wed, Nov 25, 2009 at 4:56 PM, Brent Worden <br...@gmail.com> wrote:
> On Wed, Nov 25, 2009 at 4:23 PM, Paul Benedict <pb...@apache.org> 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
>>
>> 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
>>
>
> I do not agree with the artifact/version statements. In my mind,
> different artifactId's imply the jars are companion or supplementary
> artifacts. The JDBC 3 and 4 version of commons-dbcp are drop in
> replacements of each other. To me, this implies different artifact
> versions.
>
> I do agree, that the groupId should be constant.
>
> Also, if the multiple version approach is taken, I would explicitly
> call out the JDBC version in all artifacts in order to be consistent
> and eliminate user ambiguity.
>
> Brent
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Brent Worden <br...@gmail.com>.
On Wed, Nov 25, 2009 at 4:23 PM, Paul Benedict <pb...@apache.org> 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
>
> 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
>
I do not agree with the artifact/version statements. In my mind,
different artifactId's imply the jars are companion or supplementary
artifacts. The JDBC 3 and 4 version of commons-dbcp are drop in
replacements of each other. To me, this implies different artifact
versions.
I do agree, that the groupId should be constant.
Also, if the multiple version approach is taken, I would explicitly
call out the JDBC version in all artifacts in order to be consistent
and eliminate user ambiguity.
Brent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Paul Benedict <pb...@apache.org>.
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
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 <ph...@gmail.com> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [dbcp] 1.3 release packaging - take two
Posted by Phil Steitz <ph...@gmail.com>.
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org