commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tetsuya Kitahata <tets...@apache.org>
Subject Re: [combo] Commons Core release?
Date Thu, 14 Aug 2003 04:13:40 GMT

Now, Jakarta-ORO think about one of the potentialities
of the transfer to commons-proper. (How about Regexp, ECS?)

Combo project is very attractive and useful for most of the
java engineers. Oro, Regexp, ECS can join to it, i think.

Bye bye, "too many jars" problem :-)

Sincerely,

-- Tetsuya (tetsuya@apache.org)

On Thu, 14 Aug 2003 00:02:52 -0400 (EDT)
(Subject: [combo] Commons Core release?)
Henri Yandell <bayard@generationjava.com> wrote:

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


Mime
View raw message