On Thursday, January 31, 2002, at 08:46 AM, Guillaume Rousse wrote: >> > 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.
This is absolutely a benefit of Java software. While it was technically possible to do this for C projects it was practically infeasible. In Java it is entirely feasible and works just fine in the majority of cases. > 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 :-) The issue raised was not a technical one, it was legal. Trying to put in a complex technical solution for it is overkill. The current mechanism works just fine in almost all cases. It may not be ideal, but so what; It still removes a lot more headaches then it creates. > 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. > What about the 99% of the world that uses a platform that isn't Linux? > 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, > So how is an Apache project not a packager and distributer? The perspective that open source should only be concerned with the perspective of the developer is not a good one. Plus, developers are not the only people who pull the code from CVS. I cringe at the thought of having to ensure that everybody who uses our CVS tree also needs to manually update dependencies as the software evolves. In the current mechanism the system always works. If the source changes such that it depends on an updated jar a simple CVS update will bring not only the source change but the updated jar as well. You always know that the software is supposed to build out of the box and that if it doesn't then someone is on the hook for breaking the build. To say that this isn't a unique benefit of Java is simply not true. >> > 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. Or it could simply be a network failure or server crash or maybe the software moved or maybe the person who made it available changed their mind and pulled it. Regardless of the reason you still have the dependency and the software is now useless to the user trying to install it. > > Jpackage project (http://package.org) try to provide such a consistent > set of > java software for rpm world. Debian java project Heh heh, as I write this, this site is down. :-) > (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... I'm kind of disappointed. You suggested that we break all of our software by removing all the jars from CVS and then offer a solution that will only work for an extremely small percentage of the user population. Very disappointing. BTW, -1 to the whole idea. The issue raised was legal and easily solved by simply better detailing the source of the included jars. A technical solution will take months to implement and simply removing the jars and forcing users to track their own dependencies destroys the usability of the software. > -- > 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]
