Return-Path: Delivered-To: apmail-commons-dev-archive@www.apache.org Received: (qmail 10224 invoked from network); 26 Nov 2009 15:05:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 26 Nov 2009 15:05:13 -0000 Received: (qmail 12912 invoked by uid 500); 26 Nov 2009 15:05:13 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 12762 invoked by uid 500); 26 Nov 2009 15:05:12 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 12752 invoked by uid 99); 26 Nov 2009 15:05:12 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Nov 2009 15:05:12 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jak-commons-dev@m.gmane.org designates 80.91.229.12 as permitted sender) Received: from [80.91.229.12] (HELO lo.gmane.org) (80.91.229.12) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Nov 2009 15:05:03 +0000 Received: from list by lo.gmane.org with local (Exim 4.50) id 1NDfth-0006Np-2X for dev@commons.apache.org; Thu, 26 Nov 2009 16:04:41 +0100 Received: from mail.elsag-solutions.com ([62.154.225.82]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Nov 2009 16:04:41 +0100 Received: from joerg.schaible by mail.elsag-solutions.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Nov 2009 16:04:41 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: dev@commons.apache.org From: =?UTF-8?B?SsO2cmc=?= Schaible Subject: Re: [dbcp] 1.3 release packaging - take two Followup-To: gmane.comp.jakarta.commons.devel Date: Thu, 26 Nov 2009 16:04:15 +0100 Lines: 48 Message-ID: References: <4B0DA868.2090801@gmail.com> <4B0DAC2C.7090709@gmail.com> <55afdc850911251525j206c6911j25edb72055d04da5@mail.gmail.com> <4B0DBE51.8010500@gmail.com> <55afdc850911251539h6f9a091ap34d655bc6c6d010b@mail.gmail.com> <55afdc850911251548o23614c09l31621fb725d5ae72@mail.gmail.com> <4B0DC694.9040803@gmail.com> <55afdc850911251651y2adff6ffu86c2f66ff7c200de@mail.gmail.com> <4B0E8E95.4060805@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mail.elsag-solutions.com User-Agent: KNode/4.3.1 Sender: news X-Virus-Checked: Checked by ClamAV on apache.org 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