incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: cvs commit: incubator-altrmi/lib/optional excalibur-lifecycle-1.0.jar
Date Wed, 19 Mar 2003 17:13:19 GMT

Aaron Bannert wrote, On 19/03/2003 16.31:
> On Sunday, March 16, 2003, at 11:47  PM, Nicola Ken Barozzi wrote:
>>> If they are the product of another project, then the developer
>>> would just download and build/install that other project.
>> Hmmm, so here start the problems. A Java project can have a lot of 
>> dependencies, and making all developers download all these projects 
>> and use them has been found out to be a major PITA and time killer.
>> As for installing... well java deliverables are never installed, just 
>> copied in the right dir.
> I really don't think we should be polluting CVS with JARs because
> the developers on a project are too lazy to download and copy a jar
> to the right directory.

If a developer downloads Cocoon and wants to build it, he has to track 
down something like 50-60 jars, and some he has to build himself from a 
dated CVS version (yes we do live on the edge).

It's really impractical, and hampers our possibility of having 
developers take a peek and get interested.

>>> As for these particular jars, where do they come from and what
>>> do they do? (And who owns them?)
>> The one pointed out by your original mail
>>   excalibur-lifecycle-1.0.jar
>> comes from Apache Avalon Excalibur Lifecycle.
> So this jar available directly as a download from elsewhere the ASF?

No, it has to be built from Avalon CVS.

>> Most of the projects depend mainly on Apache jars, but there are also 
>> jars from many other OS projects.
> I would think we would be very resistive to putting jars from non-ASL
> projects into our CVS repository. I don't think we want to blur the
> lines of "distribution" to invoke any licensing clauses in the other
> open-source Jars we use.
> Here are the problems I see with importing jars to CVS:
> 1) it wastes huge amounts of harddrive space


> 2) it becomes difficult and resource intensive to track minor changes in 
> those jars

Nope. We name them with the versions, so it's actually quite easy.

> 3) we unintentionally become a possible "distribution" site

Unlikely that CVS is used for "distribution", although legally it stands 

> 4) other license issues with the checked-in jars are unknown

They are known, or at least should be. The problem is the "should", 
because PMCs with a high number of subprojects did not iversee correctly 
for obvious practical reasons.

> So far, I think this far outweighs the benefits:
> 1) easier for developers to build the project

Hmmm, it's not making easier to build, but for new ones or ones that 
work on it not every day to start easily.

Anyway, I'm just trying to explain why this situation arised. It is 
driven by real need, not by laziness.

Do jars in CVS suck? They do.
Does downloading all that stuff suck. Sure it does. already has working codebases that give a solution 
to this problem to choose from. What we need is to set up the 

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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

View raw message