commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: [core] Scope, you choose!
Date Sat, 07 Dec 2002 06:11:28 GMT
I think there are 2 separate issues.

Having one big jar with all the commons code - or one big jar 
with all jakarta code - is a good idea.
So is having a distribution with 20 small jars. It's a matter
of taste, so having both is the best solution.

The issue I'm concerned with is the spaghetti that goes between
the packages, and the ability to pick one component without
having to use all jakarta.

And as a practical problem - modeler won't work without digester
which doesn't work without collections, beanutils. And digester
doesn't work well in the top loader - and who knows what else
has the same problems. As you know, there are good reasons to
be able to keep the root loader clean. It may be just another
matter of taste - but at this moment bloat ( include everything,
just in case ) wins. 

I think those are _very_ distinct problems, and we shouldn't mix them.
I fully support one big jakarta-commons.jar, as well as a distribution
that includes all the software in jakarta.
 

Costin


Craig R. McClanahan wrote:

> 
> 
> On Fri, 6 Dec 2002 scolebourne@btopenworld.com wrote:
> 
>> Date: Fri, 6 Dec 2002 18:05:53 +0000 (GMT)
>> From: scolebourne@btopenworld.com
>> Reply-To: Jakarta Commons Developers List
>> <commons-dev@jakarta.apache.org> To: commons-dev@jakarta.apache.org
>> 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
> want.
> 
> 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?
> 
> Craig




--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message