commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [combo] Commons Core release?
Date Fri, 15 Aug 2003 21:39:28 GMT
I haven't added to the debate up till now as I wanted to see how things

Firstly, my definition of 'core' is basic extensions to the JDK, no config
files, no logging, no framework.
codec (never looked at it, but may fit)
cli?? (never looked at it, but may be more framework like)

BeanUtils ought to be included, however it has been written to use logging.
I believe this to be wrong, but this is an old decision, hard to change.

JDK1.2 should be the baseline.

However, it is clear that this division is just one of many that can occur.
It makes most sense to me, but others disagree. Given the current commons
structure I would suggest agreement on the contents of core is highly

One way out would be a separate mailing list, or maybe a separate
Jakarta-Core subproject. Then a single release could be created. However,
this also seems to fail the reality check.

Originally, I supported commons core, by promoting collections, io, pattern
(deceased), beanutils to all depend on lang, thus forming a nice group. Now
it seems that the more independent absolute minimum dependencies route is
actually simpler for everyone. A little code duplication may occur, but that
is better than additional dependencies.

My answer to the users - just deal with the jars. Its not that hard, and
creating a combo or core jar creates really nasty versioning issues, as
commons projects release to their own timescales, not one. One product = One


NOTE: If Java was OSS and we were in charge of adding new functions to the
JDK, matters might be different. But as outside libraries, the midset must
be different.

----- Original Message -----
From: "Henri Yandell" <>
> Last November [I think] Craig created the Combo project. It puts a whole
> lot of Commons projects into one jar and makes them available in a much
> simpler form to users.
> This is the biggest complaint about Commons at the moment [I think], that
> we have some kind of reproduction of jars going on in which more and more
> jars appear in the user's code.
> I'd like to consider a release as such from Combo of what some of us were
> calling Commons Core a while back. It's an implementation of the Combo
> ant-scripts [currently I copy and paste, but it shouldn't be hard for me
> to make a single build.xml and a shared properties file per
> 'distribution' with enough Ant learning].
> My current criteria is that Commons Core _only_ depends on JDK1.4 [and
> cross-dependencies inside the distribution]. Currently I have:
> =====
> Apache Commons Core v1.0 consists of:
> Jakarta Commons BeanUtils 1.6.1
>     Makes the JavaBean specification easier to deal with.
> Jakarta Commons CLI 1.0
>     A command line interpreter. Used to handle all the flags passed to
> program on the command line.
> Jakarta Commons Codec 1.1
>     Common encoders and decoders.
> Jakarta Commons Collections 2.1
>     Many more implementations that fit the Collections API.
> Jakarta Commons Lang 1.0.1
>     Enhancements to classes found in java.lang.
> =======
> A url to a build is:
> I'm doing some trickery to turn BeanUtils' commons-logging dependency into
> a JDK1.4 util.logging dependency. It would be nice to add Pool, HttpClient
> and maybe Net [with some regexp trickery] and consider that a version 1.0.
> Issues I forsee
> ===============
> *) Combo has never been voted into Commons-proper. How do we handle this?
> It's not a new codebase but a release mechanism.
> *) Arguments over what goes in what. Rather than create a huge jar of
> everything, which I think is unpalatable to the user, I chose the JDK 1.4
> dependency as a strict guideline and tried to make things toe the line.
> Effectively it's a Commons-J2SE distribution for adding features to a
> new J2SE install.
> *) Testing. In Core 1.0 I've chosen the latest stable releases [except
> HttpClient which is at RC2] of each project. There are no
> interdependencies, but as projects depend on each other the building of a
> combo jar becomes trickier. This is a problem for the future probably.
> Possibly the solution is that after each component is built/tested, and
> the new uber-jar is built, the tests should be re-run against that jar.
> ====
> My general idea for Combo is that it is a tool for creating distributions
> of Commons code. These distributions are effectively configurations of
> Combo. I'm not sure if Craig is +1 or -1 for this and what his
> original plans were, but I think there's a need for a solution and that
> this is a solution.
> No idea if it's a good solution :) It seems quite fun and interesting.
> Any ideas? Flames?
> My chief two concerns are:
> 1) Can I treat Combo as a Commons Proper project.
> 2) Is the idea of a Commons Core distribution viable.
> Hen
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message