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 ([EMAIL PROTECTED]) -- On Wed, 13 Aug 2003 21:27:26 -0700 (PDT) (Subject: Re: [combo] Commons Core release?) "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote: > Comments interspersed. > > On Thu, 14 Aug 2003, Henri Yandell wrote: > > > Date: Thu, 14 Aug 2003 00:02:52 -0400 (EDT) > > From: Henri Yandell <[EMAIL PROTECTED]> > > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > > To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
