Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Date: Thu, 14 Aug 2003 00:02:52 -0400 (EDT)
From: Henri Yandell <bayard@generationjava.com>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: [combo] Commons Core release?
Message-ID: <Pine.LNX.4.44.0308132344530.20327-100000@umbongo.flamefew.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


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

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