On Tuesday, January 29, 2002, at 01:36 PM, Guillaume Rousse wrote: > > Don't import any jar back into the cvs, but fills a complete and exact > dependency list -) > > Ok, not exactly what you're looking for, but at least it could open the > debate. Outside of java world, i never saw any binary in CVS. Instead > there > are README files telling: you need libfoo-x.y.z and libbar-x.y.z to build > this soft.
And this is one of the great benefits of Java software. Having to track down all the dependencies is a major PITA for the user of the software. A lot of this stuff is hard enough to get going, why introduce more pain. This just seems like the wrong solution for a problem that is primarily a legal rather then technical issue. > 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. > So, why not profit of the big CVS clean-up to adopt more coherent > practice ? > -- > Guillaume Rousse <[EMAIL PROTECTED]> > GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html > > --------------------------------------------------------------------- > In case of troubles, e-mail: [EMAIL PROTECTED] > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > Kimbro Staken XML Database Software, Consulting and Writing http://www.xmldatabases.org/ --------------------------------------------------------------------- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
