lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <>
Subject Re: Distributable JAR filename
Date Fri, 25 Jan 2002 13:15:42 GMT
From: "Andrew C. Oliver" <>
> > Most Jakarta projects currently do it differently that Lucene's current
> > procedure, so I'm not proposing anything unusual.
> >
> IMHO They are wrong.

:)  At least we all have our own strong opinions on this issue.

> -1..  Yes..  Think of the situation where you have two unknown versions
> of the jar...  It is very easy to cause the java version of DLL hell.
> Yet by simply looking at the jar in your classpath or web container you
> can see which one to zap or rename to mud.
> This doesn't solve the problem but it sure as heck makes it obvious.

Version information can be embedded inside the JAR as a properties file or
in the manifest, so its would be easily identifiable.

I certainly can see both sides of this issue, but my overriding thoughts are
that upgrading to a new version of Lucene should be as easy as pointing a
build to a new directory and not dealing with JAR file name changes too.  I
believe classpaths should be tightly controlled and using Ant this means
that a <path> is constructed pointing to exact JAR files (and not to include

Suppose I have a project that is using Lucene and, of course, is using an
Ant build.  How should my build be flexible enough to handle the upgrade of
a new version of Lucene without the build file itself having to be modified?
I'm curious how you handle this situation.  I have a technique that I've
developed that works nicely, even with Lucene's scheme (because at least its
JAR file name is the same as distribution directory name) but it works even
nicer with JAR's named the same.


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

View raw message