Salut, > > There's no need to update both the groupId and tthe artifactId. > So long as the each unique package name relates to a unique > groupId:artifactId pair, Maven should be able to resolve dependencies > correctly. >
Yes it does, the issue is not technical but rather keeping coherence with previous cases, indeed I mentioned past experiences with pool2 [1] (o.a.c:commons-pool2) and digester3 [2] (o.a.c:digester3) where we agreed on updating both - what is the reason to make an exception with chain? > > Changing package name causes lots of work for downstream users. > Yes, I agree, anyway we spoke about the plan of releasing a major version of the [chain] component... > So are you sure that: > - compatibilty has to be broken in order to support the changes that > have been made? The main big impact is changing the Command/Chain#execute() method signature supporting the Map<K,V> as context, as we discussed last year - since we > - there aren't any other pending API changes that would require > another package rename for the next release? > Do you mean components that dependes to chain? Just for the record, clirr report of chain2 [3] has been updated on my personal space, so people can discuss about changes. thanks for the feedbacks, -Simo [1] https://svn.apache.org/repos/asf/commons/proper/pool/trunk/pom.xml [2] https://svn.apache.org/repos/asf/commons/proper/digester/tags/DIGESTER3_3_0/pom.xml [3] http://people.apache.org/~simonetripodi/chain2/clirr-report.html http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ > > There's no need to update both the groupId and tthe artifactId. > So long as the each unique package name relates to a unique > groupId:artifactId pair, Maven should be able to resolve dependencies > correctly. > > However it is easier to keep the artifactId in step with the package name. > >> Any objection? > > Changing package name causes lots of work for downstream users. > > So are you sure that: > - compatibilty has to be broken in order to support the changes that > have been made? > - there aren't any other pending API changes that would require > another package rename for the next release? > >> TIA, >> -Simo >> >> [1] https://issues.apache.org/jira/browse/CHAIN-58 >> >> http://people.apache.org/~simonetripodi/ >> http://simonetripodi.livejournal.com/ >> http://twitter.com/simonetripodi >> http://www.99soft.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
