On Wed, 13 Aug 2003, Craig R. McClanahan wrote:

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

I'm with Craig on this. +0 to a "combo" that contains everything in
commons (even httpclient) in a single JAR (and we'll cross our fingers
that won't introduce any versioning issues.)  -1 anything like
"commons-core" that tries to pick and choose which products the user is
likely to want.  This is impractical at best, and political at worst.

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

This is probably better suited to another thread, but I'm -1 on making
BeanUtils require JDK 1.4.



With respect to versioning of something like commons-combo, I'd rather see
either: (1) straight incremental version numbers--"release 1",
"release 2", ... , "release n"--or (2) a straight date based
system--"17 Aug 2003", "23 Sept 2003", etc.  Anything else is going to
confuse the suitation more than clarifying it.  If you want to know which
specific versions of each component are contained, you're gonna have to
look at the release notes anyway.

- Rod <http://radio.weblogs.com/0122027/>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to