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 19:48:20 GMT
On Fri, 2002-01-25 at 15:00, Paulo Gaspar wrote:
> Eric,
> 
> I do not see why having the version in the name makes upgrading harder.
> 

+1

> A developer can always decide to rename the luceneXXXX.jar to lucene.jar
> all the time he upgrades and there is no trouble with configuration
> anymore. The effort to do this is minimal.
> 

+1

> OTOH, having the version showing makes checking what version I am using
> much faster if I am using something like Tomcat - where any jar placed
> in WEB-INF/lib is added to the servlet's "classpath". And renaming is
> in this case harder and error prone.
> 

+1

> Have fun,

+1

> Paulo Gaspar
> 
> 
> > -----Original Message-----
> > From: Erik Hatcher [mailto:lists@ehatchersolutions.com]
> > Sent: Friday, January 25, 2002 7:59 PM
> > To: Lucene Developers List
> > Subject: Re: Distributable JAR filename
> >
> >
> > ----- Original Message -----
> > From: "Andrew C. Oliver" <acoliver@apache.org>
> >
> > > 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.
> >
> > Here's a more concete example.  How would you go about upgrading to JUnit
> > 3.7 for Lucene builds?  (I see that version 3.5 is whats there now by the
> > filename, which must have been renamed from the JUnit distribution)
> >
> > The only way possible now (without risking class clashes) is to put the
> > version 3.7 JAR into the lib directory and remove the 3.5 version JAR.
> > Correct?
> >
> > This is whats in Lucene's build.xml:
> >
> >   <path id="junit.classpath">
> >     <pathelement location="${junit.classes}" />
> >     <pathelement location="${build.classes}"/>
> >     <fileset dir="lib">
> >       <include name="*.jar" />
> >     </fileset>
> >     <pathelement path="${java.class.path}" />
> >   </path>
> >
> > What I do is have properties pointing to each individual JAR file -
> > ${junit.jar} for example, and construct <path>'s from those rather than
> > "*.jar" inclusion.
> >
> > I am able to simply flip a switch for my builds to get to a new version of
> > Lucene:
> >
> >     ant -Dlucene.version=1.2-rc3-dev
> >
> > and then everything else would adjust from there.  Again, my scheme works
> > "ok" with Lucene since the directory and JAR have the same name.  I was
> > merely making a suggestion based on my experience on how pulling in new
> > versions of Lucene could be a bit easier - but no big deal that its not
> > acceptable to lucene-dev.
> >
> > But think about this issue in terms of Lucene's own build, and
> > the JUnit JAR
> > situation above.  Lucene's own build is not flexible enough to
> > handle a new
> > version easily.
> >
> >     Erik
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> > <mailto:lucene-dev-help@jakarta.apache.org>
> >
> 
> 
> --
> 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