xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Rousse <rou...@ccr.jussieu.fr>
Subject Re: URGENT: 3rd Party jar's in apache CVS need immediate action.
Date Thu, 31 Jan 2002 15:46:14 GMT
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 

> - 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 <rousse@ccr.jussieu.fr>
GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html

In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

View raw message