Danny Angus wrote:
Nicola,I respect your POV, but I disagree :-)
;-P
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? ;-)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.
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.
For upgrades... it would take more than that, with all the possible other changes that have to be done...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.
Sorry, I'm not sure I get this.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.
"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 %-)
I don't get this. What about "complicated install"?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.
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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
