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:[EMAIL PROTECTED]] > Sent: Friday, January 25, 2002 7:59 PM > To: Lucene Developers List > Subject: Re: Distributable JAR filename > > > ----- Original Message ----- > From: "Andrew C. Oliver" <[EMAIL PROTECTED]> > > > 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:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
