james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Download jars instead of keeping in CVS?
Date Mon, 03 Feb 2003 16:02:21 GMT

Danny Angus wrote:
> Nicola,
> 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.

This seems pretty speculative IMHO. Look at the jar manifests we have. 
Look at the filenames. Which of the two is more uptodate WRT the 
version? ;-)

I don't think at all that file naming is the final or best solution, but 
ATM it's IMHO the most reasonable and cost-effective one.

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

For upgrades... it would take more than that, with all the possible 
other changes that have to be done...

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

Sorry, I'm not sure I get this.

"get version a.b.c of library x, if and only if they don't already have 
it" is what I'm advocating. Versioning is taken care of.

And I don't see why this would impact the convenience of more advanced 
users %-)

> 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

I don't get this. What about "complicated install"?

Oh, maybe I was not clear. I am not talking about James *releases*, 
which IMHO should for now have all the jars included for now.

I'm talking about using this task to get the jars for those who get the 
code from CVS or snapshots.

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

Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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

View raw message