commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: [combo] Commons Core release?
Date Thu, 14 Aug 2003 04:27:26 GMT
Comments interspersed.

On Thu, 14 Aug 2003, Henri Yandell wrote:

> Date: Thu, 14 Aug 2003 00:02:52 -0400 (EDT)
> From: Henri Yandell <bayard@generationjava.com>
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> Subject: [combo] Commons Core release?
>
>
> 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.
>

That was one issue.  Another was the potential for having different
packages require different versions of the same commons package.

> 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:

Trying to define "combo" as anything other than "the latest released
version of every Commons package" seems like it's guaranteed to cause
arguments.  The collection you propose below, for example, is totally
useless to me and all the projects I work on.  But commons-combo as it is
currently built would be useful to me, and to you, and to anyone else.

>
> =====
> 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 your
> 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: http://www.apache.org/~bayard/commons-core/
>
> 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.
>

We can talk about that on a [beanutils] specific thread, but I'd be -1 on
doing this to the real BeanUtils code.  A very large number of BeanUtils
users do not have the luxury to run on a 1.4 JDK.

> 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.
>

It should be voted as a formal package (with a defined release mechansim
like "every time an included package rolls a new release, then roll a new
combo release as well.")

Of course, this is going to run into difficulties if/when included
packages start making backwards-incompatible API changes (like on version
1.x to version 2.x transitions), but so far Commons developers have been
pretty sensitive to that.

> *) 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.


I'm -1 on subsetting commons-combo to be less than a combination of all
released Commons packages.  Trying to say what things are "core" and what
are not is just fodder for flamewars.

I'm +0 on setting up the combo build.xml file in such a way that you can
do your own custom subsets.

>
>
> Hen

Craig

Mime
View raw message