For someone who uses Commons Collections a lot in their applications, this is going to be quite a pain if I want to upgrade. Yes, I realize that there's such a thing as find and replace, but the fact that I have to do that if I want to upgrade is just a bother. That's my $0.02.
On 10/25/06, Jörg Schaible <[EMAIL PROTECTED]> wrote:
Hi Kris, Kris Nuttycombe wrote on Tuesday, October 24, 2006 5:10 PM: >>> (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. well, I don't think this is necessary for complete commons, but we may consider doing so for major releases of the individual componnets. Collections might have org.apache.commons.collections4 for the next major version ... and so it would not interfere with older versions, have individual groiupIds (concerning Maven) and the artifacts can coexist, the version scheme is not dependent on the JDK and the minimal JDK requirement can be changed easily. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
