lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: two versioning problems with Lucene
Date Wed, 08 Dec 2004 14:09:08 GMT
On Dec 8, 2004, at 6:58 AM, Andrzej Bialecki wrote:
> Erik Hatcher wrote:
>> 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 
> file, containing these numbers. Quite simple and 
> bulletproof - you change version numbers in one place only.

Yes, I'm quite familiar with how to do these things with Ant, and will 
even take care of whatever facility we agree upon based on this 

Perhaps I'm being misunderstood in this discussion.  I'm playing 
devil's advocate a bit here by posing the options other than creating 
this Java class.  The MANIFEST.MF is the "standard" way to keep this 
version information, and we're already encoding the version number in 
*two* places 1) the JAR filename 2) the manifest.

Are folks proposing we drop the existing two version numbers and 
convert to using the Java class?  Or are you proposing we add a a 
*third* place where we store this information.

I would prefer we have a _single_ authoritative unambiguous 
representation of the version number.

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

The manifest allows for programmatic access, as has been shown.

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

I would argue (again, playing devil's advocate, not necessarily with 
any personal preference in this way) that you should adjust your 
deployed manifest to have the Lucene version in it too.  If you're 
going to repackage Lucene, then perhaps you should also be responsible 
for ensuring your manifest makes Lucene's versioning facility happy.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message