(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
One possibility that occurs to me is that we could take the problem to a
higher level. Since a number of projects are going to be facing this
problem, what about a package rename at the "commons" level - say,
org.apache.commons2 or org.apache.commons5? This way, the Maven problem
and the package rename problems can be solved, and yet we can still keep
the individual "brand" names untainted. This can also scale with new JDK
releases - you would end up with a "commons" for each release where you
have a binary incompatible break, but this seems less obnoxious to me
than having each project have to keep up with a component-level naming
scheme.
Kris
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
