james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <da...@apache.org>
Subject RE: Download jars instead of keeping in CVS?
Date Mon, 03 Feb 2003 15:17:02 GMT

I respect your POV, but I disagree :-)

> Instead of maintaining the jars in CVS, what I mean is that you can use 
> an Ant task that downloads them from a repository. RuperTask does just 
> that. Specify the jars in an xml descriptor and have them downloaded.

That I understand, but it does depend upon the jars being available from the repository, and
unless I've missed something would also rely on filenames for version information. Versioning
jars in a proper version control system ought to defeat any possibility that versions could
change without appropriate filename changes. 
I am totally opposed to using filename nameing schemes for any critical information at all,
I believe that it is lazy and sloppy design, it is too easy to break and can seriously restrict
reasonable use by users. In your system what would happen if a user independantly sourced
an upgrade to a library jar? I think she would have to rename that file to match the filename
expected by the system, and end up mis-representing the new version as the older one, no?
Filenames should be used IMO only for distinguishing between files, filenames should not be
used to store data for machines' use, only for human consumption. IMO machine read meta data
should be contained in the file itself.

On the other hand (I like to keep an open mind :-) I can see how this would benefit everyone
for upgrades, instead of downloading james at all there could be an upgrade installer which
used this, and some other trickery, to only replace those files which have changed.

> This would also download the Apache bandwidth usage and make it possible 
> for users not to download many times the same jar from each project.

Well, James is mirrored, as we like to be a good apache citizen. And the problem I have with
allowing users to avoid downloading jars is versioning.
Unless there would be a foolproof way to ensure our users could easily get version a.b.c of
library x, if and only if they don't already have it, then I'd favour the needs of the less
competent user over the convenience of the more advanced ones.

What it boils down to is that unless or until someone produces some kind of intelligent registry
for jars perferably at JVM level, I'd rather subject our advanced users to the task of deleteing
the jars they don't need, than risk alientating new users with a complicated install.

Its probably worth mention that Microsoft .NET's "Common Language Runtime" "Global Assembly
Cache" for "Shared Assemblies" provides this service for .NET, because as M$ were plagued
for years by "DLL hell" the solution to that problem was very much needed and is well conceived.
It allows for the simultaneous installation of several versions of the same library, includes
signed "strong" names, and pretty much addresses every concern related to library versioning,
installation, security and dependancies that Java has no answer too.
If there was a real Java, or even Apache, equivalent I'd use it.


To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org

View raw message