xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kimbro Staken <ksta...@dbxmlgroup.com>
Subject Re: URGENT: 3rd Party jar's in apache CVS need immediate action.
Date Thu, 31 Jan 2002 19:54:44 GMT

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 

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 <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
Kimbro Staken
XML Database Software, Consulting and Writing

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