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 05:24:19 GMT

By the way, how about 
"Commons-Core_August_2003" or something equivalent to it,
rather than "Commons-Core V1.0" ... ??

We are taking the list of "Products available as of the end of ***,
year 200X" ... So, "Commons-Core_(Month)_YYYY.jar"-styled package name
would be ideal and make sense .... Comments please ;-)

-- Tetsuya (tetsuya@apache.org)

--

On Wed, 13 Aug 2003 21:27:26 -0700 (PDT)
(Subject: Re: [combo] Commons Core release?)
"Craig R. McClanahan" <craigmcc@apache.org> wrote:

> 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