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. 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. d. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
