lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <acoli...@apache.org>
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" <acoliver@apache.org>
> > > 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
parameter.  

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.

-ACO

>     Erik
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>
> 
-- 
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
			- fix java generics!


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


--
To unsubscribe, e-mail:   <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>


Mime
View raw message