Oh I've been reading :-) I participated in the Lang 3 decision and we decided (1) new package name (2) new groupId (3) same artifactId.
Why do you think you need to change the artifactId? Look below and tell me what you don't like about this progression. commons-dbcp:commons-dbcp:1.4 org.apache.commons:commons-dbcp:2.0 org.apache.commons:commons-dbcp:3.0 Paul On Sat, Oct 16, 2010 at 11:29 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > On 10/16/10 11:02 PM, Paul Benedict wrote: >> >> If you are changing the groupId, there's no point in changing the >> artifactId. > > See related discussion on [pool]. While we can avoid changing the > artifactId for 2.0 since the groupId change creates the necessary separation > of artifacts, we will need to do it subsequently. I agree with James and > others that it is best to maintain the simple convention that at least for > low-level components, we tie the artifactId to the major release series. > > Phil > >> >> On Sat, Oct 16, 2010 at 9:38 PM, Phil Steitz<phil.ste...@gmail.com> >> wrote: >>> >>> I just created a dbcp 1.4 legacy branch, so we can now start work toward >>> dbcp 2.0 in trunk. Pool is already off to the races. As we have >>> discussed, >>> I would like to start exploring bringing in the Tomcat jdbc-pool code, >>> split >>> somehow between [pool] and [dbcp]. >>> >>> To get [dbcp] moving, I would like to make the following pom changes in >>> trunk: >>> >>> 0) change the groupId to org.apache.commons >>> 1) change the artifactId to commons-dbcp2 >>> 2) change the pool dependency version to 2.0-SNAPSHOT >>> >>> Both 1) and 2) may be controversial, so I want to allow people to weigh >>> in >>> before making these changes. I know we like to avoid snapshot >>> dependencies, >>> but I don't see any other way to keep the API changes in synch. Any >>> better >>> ideas? >>> >>> Thanks! >>> >>> Phil >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
