On Dec 8, 2004, at 4:24 AM, John Haxby wrote:
Otis Gospodnetic wrote:
The corollary of which is that if the version number is in two places, one of them will be wrong.Any such custom hack requires maintenance, even if it's auto-generated.
And this is what I've been alluding to. DRY is a principle I strongly subscribe to - Don't Repeat Yourself.
You don't have to repeat yourself. You can put version numbers in only one place - in the build.xml. Then write a task that creates a Version.java file, containing these numbers. Quite simple and bulletproof - you change version numbers in one place only.
As an aside: In one of my past projects we had a number of shell scripts (the build was Makefile-driven) which would extract RCS tags from files and build a complete versioning db for each class. We used to have many experimental builds, and it was important for testers and developers to know which version of which class was used to produce the results.
IMHO programmatic access to version and compatiblity info is important for many applications, and should be facilitated - especially since it's very simple to add it.
Notice also that the Lucene version number is part of the filename of the JAR: lucene-1.4.3.jar. This is good enough for my purposes of seeing which version of Lucene I'm using visually. I don't rename my JAR files.
FWIW, I routinely repackage all jars and run an obfuscator on the resulting jar - not only to protect my proprietary code, but also to reduce the size of the deployment package - both for standard installations and for WebStart.
-- Best regards, Andrzej Bialecki
------------------------------------------------- Software Architect, System Integration Specialist CEN/ISSS EC Workshop, ECIMF project chair EU FP6 E-Commerce Expert/Evaluator ------------------------------------------------- FreeBSD developer (http://www.freebsd.org)
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
