lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <>
Subject Re: Distributable JAR filename
Date Fri, 25 Jan 2002 15:20:58 GMT
On Fri, 2002-01-25 at 08:15, Erik Hatcher wrote:
> 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
> "*.jar").
> 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.

I'm not quite as familiar with POI's new Apacheized (we've adapted the
same standard build as Avalon, Cocoon and other projects with minor
improvements), but until recently at least we've used a command line

I'll have a different opinion on this once there is *real* versioning
introduced into the jar/jdk.  (I could have sworn I saw a JSR on this),
until then...   I like knowing what I have just by looking at it.


>     Erik
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>
-- - port of Excel format to java 
			- fix java generics!

The avalanche has already started. It is too late for the pebbles to
-Ambassador Kosh

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

View raw message