commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [core] Scope, you choose!
Date Sat, 07 Dec 2002 02:35:12 GMT

On Fri, 6 Dec 2002 wrote:

> Date: Fri, 6 Dec 2002 18:05:53 +0000 (GMT)
> From:
> Reply-To: Jakarta Commons Developers List <>
> To:
> Subject: Re: [core] Scope, you choose!
> My mail was meant to emphasise the different ideas/companents/packages
> that have been mentioned over time. In particular they are the ones that
> are about assisting development with the 'core' of the JDK.
> I would suggest that if we follow the charter, and all of its
> theoretically marvellous principles, then we end up with lots and lots
> of small jars.

Lots of JARs isn't necessarily bad, if your development environment makes
it easy to dynamically build classpaths (like Ant does).  However, there
are often going to be cases where you'd really like a "bunch o commons
JARs" all together, to make life easier.  The political challenge is, who
gets to define what is included in the bunch?

I tried to punt on this issue with the "combo" project, which includes a
specified released version of *all* the packages in jakarta-commons (but
not the sandbox).  Currently, this thing actually builds (except for
Latka, but that's most likely an issue on my development platform), ending
up with a JAR file of just over one megabyte.  As a side benefit, it
generates consolidated Javadocs for the packages that are included.

The theory is that most people will want a JAR that contains the latest
released version of all the JARs, so that is how the build is set up.
Presumably, any time a Commons package was released, the CVS tag to pull
for that package would also be updated in the combo build.xml file.
However, because each of the tags is itself an Ant property, it is very
easy to use this to grab exactly the combination of versions you want.  It
also would be straightforward to set up mechanisms where you can subset
this -- right now you'd just have to comment out the things you don't

Rather than getting into emotional discussions of "core" versus
"non-core", how about if we start with "combo" that includes *all* the
non-sandbox packages, and work from there?


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message