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 Mon, 04 Feb 2002 18:41:24 GMT
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 

> > 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 <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