On 10/23/06, James Carman <[EMAIL PROTECTED]> wrote:
Tomcat has been able to do this without any real problems.
<snip/>
Because now (TC6, some in 5.5, maybe other branches too) they've package renamed dependency artifacts (digester, logging, dbcp -- and even hinted at JDT ;-). -Rahul
Why can't we just keep the Commons Collections name (and packages, etc.), but just use the version numbers to keep it straight? Tomcat 5.5.x requires JDK5. Couldn't we just say that Commons Collections 4.x (and beyond) requires JDK5? That way, for those folks who want to upgrade, it's not very tough. For the most part, the classes/methods will have the same names. On 10/23/06, Jörg Schaible <[EMAIL PROTECTED]> wrote: > > Hi Stephen and Henri, > > Stephen Colebourne wrote on Saturday, October 21, 2006 5:20 PM: > > > Henri Yandell wrote: > >> Why not just start a branch within Collections? > >> > >> I don't see why this is a new component, are we going to be advising > >> people to use Collections 3.x on JDK 1.5+ for any reasons other than > >> legacy or instability of our generified version? > >> > >> My view is to make a collections-generics branch in collections with > >> a view to it being Collections 4.0. > > > > Because commons isn't like other OSS projects. We can't go around > > changing our APIs freely, even between major versions. Its a > > simple case > > of us being at the bottom of the stack of jars. If we do > > change an API, > > any API then jar hell ensues because higher OSS projects will > > clash on > > their required versions of [collections]. > > > > Thus, it has to be a new package, and this is best thought of > > as a new > > component. > > It is also about branding. Collections is a well-known name in the > community. Think of three years from now. If we declare collections 4.xneeds JDK > 1.5+ now, in 3 years nobody will rermember, that the older versions did > support JDK 1.3. But the name for collections still persist. That's the > political reason, not to change the name. > > > (Compare this with the JDK where they had to jump through ridiculous > > hoops to make generics fully backwards-compatible, and created a > > half-arsed mess in the process...) > > This is the real problem. We must use a different namespace for the Java > package itself. A lot of stuff depends on c-c ( > http://www.mavenregistry.com/search/artifact/19973 + > http://www.mavenregistry.com/search/depended_upon_artifacts, quite > impressive) and even in 3 years there will be stuff available that still > depends on those old versions. > > A new package name solves the problem of coexistence as long as the jar > name contains the version (e.g. commons-collection-3.1 & > commons-collection-4.2) but it creates new problems for e.g. Maven, that > cannot handle two (binary distinct) versions at the same time. > > So there are three points to decide: > - does a new package name imply a different Jakarta Commons project? > - shall we give up existing brands (it means in the end the establishment > of a new brand for all commons projects)? > - if we keep the project name, do we have to accept the inevitable limits > of popular tools such as Maven? > > - Jörg >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
