Ainsi parlait Kimbro Staken : > 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. Perl is also multi-platforms, and doesn't rely on blind code duplication everyhwere, AFAK. Instead, they use dependencies.
> > 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. The current system is simple and functionnal, right, but it is ugly. And it is *really* a nightmare for people wanting to have a proper packaging policy, as Linux distribution for instance. > > 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? In open-source world this is usually *a bit* more. And there have been proposition recently of extending rpm use to any Unix. See http://www.openpkg.org > > 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. Apache project is only a distributer for apache project software. Java world is not limited to ASF :-) > 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. Why manually ? You have ant task for this... > 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. The current mechanism also force you sometimes to use out-dated software, just because developpers were not aware of compatibility breaks. It happened recently with ArgoUML, which could not work with xerces-j > 1.2., which was a nightmare to figure. This is clearly a developper task, not a user task. Projects as gump try to achieve the same result. > > 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. :-) My fault, it's http://www.jpackage.org, or http://jpackage.sourceforge.net > > (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. My proposition was rather: as we are currently cleaning the CVS, why not jump on the event to look for better solutions. > 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. Are users just idiots unable to read a README file ? Are developpers unable to setup a clean and practical organisation ? I don't think so... -- 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]>
