Ainsi parlait Kimbro Staken : > 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. I don't think this is really a *benefit* of Java software. Nothing prevent a native software to provide staticaly-linked binaries of make for every existing platforms in CVS. The fact that one only ant binary for Java software is enough doesn't make it an acceptable practice. Keeping track of dependencies is the task of a package management system, which only exist for Unix AFAK, while Java is multi-platform. But when this means 'propagating nasty platforms-specific constraints everywhere', i think we reach limits of cross-platform possibilities :-)
> > 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. Users relying on packaged software just have to use apt-get (for debian packages) or uprmi (for rpms packages) to have automated dependencies resolution, remote package fetching, and so on. > - 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. Ensuring a consistent set of jars is not the task of developpers IHMO, but of packagers and distributers. Moreover, unless you are strictly self-dependant, as some peoples propose it, this consistency will concern only other software part of the same project, unless you want to duplicate everything outside of ASF. > - You run the risk of a required dependency becoming unavailable which > makes the software unusable. If a dependency becomes unavailable, i think there is a reason behind (obsolescence, upgrade, security hole, etc). By short-circuiting the effect, you prevent normal evolution to takes place. Jpackage project (http://package.org) try to provide such a consistent set of java software for rpm world. Debian java project (http://people.debian.org/~tora/java/packagelist.html) provide the same service for debian world. Both try also to enforce nomal Unix conventions (FHS, etc...) and establish cross-project packaging policies. We all know this only adress a subset of java realm, so we don't ask for dropping other platforms support. We just ask to make it an optional additional layer, not make it mandatory as it is currently... -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
