Re: URGENT: 3rd Party jar's in apache CVS need immediate action.
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
Re: URGENT: 3rd Party jar's in apache CVS need immediate action.
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]
Re: URGENT: 3rd Party jar's in apache CVS need immediate action.
Ainsi parlait Guillaume Rousse : [..] 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... Something i forgot to say: all package provided at http://jpackage.sourceforge.net/packages.php are build by first deleting all jar present in the archive, and relying on other packages which are build from source also. Yes, it is a lot of work, but it is possible... -- 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]
Re: URGENT: 3rd Party jar's in apache CVS need immediate action.
Ainsi parlait Stefano Mazzocchi : [..] Don't get me wrong, I'm not against this. But the above are words, I need something that works and jars in CVS (with the license and description of where they were from attached) work best for me. As a kind of shamefuly self-publicity, jpackage project used initially package-management-system independent xml software descriptors, that you could find in project CVS here: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jpackage/xml-spec As we produced initially different rpms for different Linux distributions, we produced them from the same stem. This could easily have been extended to other packaging system, with something as soft description [.. system independant software description .. ] /description rpm [.. instruction for building rpm for this software .. ] /rpm deb [.. instruction for building deb for this software.. ] /deb autoinst [ .. instruction for building an auto-installable archive.. ] /autoinst /soft -- 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]
Re: URGENT: 3rd Party jar's in apache CVS need immediate action.
On Tue, 29 Jan 2002, Guillaume Rousse wrote: So we now have three proposed ways forward: Option 1.1 Each project put's their jar's back in - but according to the guidelines below. Option 2.2 We create a 'xml-third-party' repository for all the third party jar's. Following the guide lines below. So we keep all 3rd party and alien code in one place. Option 2.3: Don't import any jar back into the cvs, but fills a complete and exact dependency list -) Opinions ? Dw. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: URGENT: 3rd Party jar's in apache CVS need immediate action.
So we now have three proposed ways forward: Option 1.1 Each project put's their jar's back in - but according to the guidelines below. Option 2.2 We create a 'xml-third-party' repository for all the third party jar's. Following the guide lines below. So we keep all 3rd party and alien code in one place. Option 2.3: Don't import any jar back into the cvs, but fills a complete and exact dependency list -) I agree with Guillaume, 2.3 is the cleanest way and the easiest to give coherent dependencies. And It raise another question, that you could require different versions of the same API and so could have to introduce a jar renaming, as does jakarta-regexp, ie jakarta-regexp-1.2.jar. And when you have solved that, you're ready to have all jars in the same location, ie /usr/share/java/ as used in jpackage project (I'm involved in it with Guillaume) and debian-java. Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
