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:[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]> > -- 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
