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
true
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 IIUC but IANAL.
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.
[EMAIL PROTECTED] already has working codebases that give a solution to this problem to choose from. What we need is to set up the infrastructure.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
