lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <paulo.gas...@krankikom.de>
Subject RE: Distributable JAR filename
Date Fri, 25 Jan 2002 20:00:43 GMT
Eric,

I do not see why having the version in the name makes upgrading harder.

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.

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.

Have fun,
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>


Mime
View raw message