lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <li...@ehatchersolutions.com>
Subject Re: Distributable JAR filename
Date Fri, 25 Jan 2002 18:59:13 GMT
----- 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>


Mime
View raw message