-----Original Message----- From: Kimbro Staken [mailto:[EMAIL PROTECTED]] Sent: January 29, 2002 9:12 PM To: [EMAIL PROTECTED] Subject: Re: URGENT: 3rd Party jar's in apache CVS need immediate action.
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. Regards, Arved Sandstrom --------------------------------------------------------------------- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
