xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arved Sandstrom" <Arved...@chebucto.ns.ca>
Subject RE: URGENT: 3rd Party jar's in apache CVS need immediate action.
Date Wed, 30 Jan 2002 01:41:43 GMT
-----Original Message-----
From: Kimbro Staken [mailto:kstaken@dbxmlgroup.com]
Sent: January 29, 2002 9:12 PM
To: general@xml.apache.org
Subject: Re: URGENT: 3rd Party jar's in apache CVS need immediate

On Tuesday, January 29, 2002, at 01:36 PM, Guillaume Rousse wrote:
>> Putting dependencies in CVS is nasty because:
>> - you make release tarballs biggers
>> - you end up with lots of duplicated files on your box
>> - you give headache to external people wanting to package the soft
>> properly
>> for computing exact dependencies (but what version of foobar is this
>> foobar.jar exactly ?)
>> - you can't follow external dependencies evolutions, as you use a static
>> one

> Some arguments against it.
> - You increase the pain for users significantly, it might be ok for
> developers who are going to have lots of jars and know where they are, but
> an end user won't want to deal with that. Java enables the problem to be
> solved in a way that was very difficult to accomplish with C.
> - Increased pain for users means decreased usage of the software.
> - Since many developers start out as users, fewer users means fewer
> developers.
> - Not shipping a consistent set of jars increases the support headache
> significantly.
> - You run the risk of a required dependency becoming unavailable which
> makes the software unusable.

It's that last observation, Kimbro, that really defeats what would otherwise
be the best solution, IMHO, which is to supply the end-user with a package
manager (a la cygwin, or ActiveState PPM, or more recently proposed ideas),
which embodies all the knowledge about versioning and consistency and what
needs to be got from where, but reduces the necessity for individual
projects to bunde everything, which I abhor. Right now FOP, being near the
top of one food-chain, bundles xerces and xalan and logkit and batik and so
on and so forth, and it shouldn't have to bundle _any_ of that. Again, IMHO.

The user just wants a nice automated procedure that ultimately delivers a
buildable and runnable system.

That last point you make is defintely a concern of mine. It is ultimately
solved only by striving for one-stop shopping, that is, all ASF projects
should only have dependencies on other ASF projects (I don't know how
realistic this is but I suggest it as a goal). And we ensure that
dependencies are made known and nothing gets zapped without coordination.

Arved Sandstrom

In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

View raw message