lucene/default.properties

66 lines
1.6 KiB
Properties
Raw Normal View History

# -------------------------------------------------------------
# D E F A U L T L U C E N E B U I L D P R O P E R T I E S
# -------------------------------------------------------------
#
# DO NOT EDIT THIS FILE IN ORDER TO CUSTOMIZE BUILD PROPERTIES.
# CREATE AND EDIT build.properties FILE INSTEAD.
#
name=lucene
Name=Lucene
version=1.3-dev1
year=2000-2002
final.name=${name}-${version}
Revised internal search APIs. Changes include: a. Queries are no longer modified during a search. This makes it possible, e.g., to reuse the same query instance with multiple indexes from multiple threads. b. Term-expanding queries (e.g. PrefixQuery, WildcardQuery, etc.) now work correctly with MultiSearcher, fixing bugs 12619 and 12667. c. Boosting BooleanQuery's now works, and is supported by the query parser (problem reported by Lee Mallabone). Thus a query like "(+foo +bar)^2 +baz" is now supported and equivalent to "(+foo^2 +bar^2) +baz". d. New method: Query.rewrite(IndexReader). This permits a query to re-write itself as an alternate, more primitive query. Most of the term-expanding query classes (PrefixQuery, WildcardQuery, etc.) are now implemented using this method. e. New method: Searchable.explain(Query q, int doc). This returns an Explanation instance that describes how a particular document is scored against a query. An explanation can be displayed as either plain text, with the toString() method, or as HTML, with the toHtml() method. Note that computing an explanation is as expensive as executing the query over the entire index. This is intended to be used in developing Similarity implementations, and, for good performance, should not be displayed with every hit. f. Scorer and Weight are public, not package protected. It now possible for someone to write a Scorer implementation that is not in the org.apache.lucene.search package. This is still fairly advanced programming, and I don't expect anyone to do this anytime soon, but at least now it is possible. Caution: These are extensive changes and they have not yet been tested extensively. Bug reports are appreciated. git-svn-id: https://svn.apache.org/repos/asf/lucene/java/trunk@149922 13f79535-47bb-0310-9956-ffa450edef68
2003-01-13 18:50:34 -05:00
debug=on
project.name = site
docs.src = ./xdocs
docs.dest = ./docs
src.dir = ./src/java
demo.src = ./src/demo
demo.jsp = ./src/jsp
test.src = ./src/test
docs.dir = ./docs
dist.dir=${final.name}
dist-src.dir = ${final.name}-src
# javadoc packages
packages=org.apache.lucene.*
# javadoc link
javadoc.link=http://java.sun.com/j2se/1.4/docs/api/
build.compiler.pedantic=false
build.dir = ./bin
build.classes = ${build.dir}/classes
build.lib = ${build.dir}/lib
build.javadocs = ${build.dir}/docs/api
build.src = ${build.dir}/src
build.encoding = ISO-8859-1
build.manifest = ${build.classes}/MANIFEST.MF
build.demo = ${build.dir}/demo
build.demo.src = ${build.demo}/src
build.demo.classes = ${build.demo}/classes
build.demo.name = ${name}-demos-${version}
build.demo.war.name = luceneweb
build.docweb = ${build.dir}/docweb
build.docweb.war.name = lucenedocweb
build.test = ${build.dir}/test
build.test.classes = ${build.test}/classes
junit.src = ${basedir}/src/test
junit.classes = ${build.dir}/unit-classes
junit.reports = ${build.dir}/unit-reports
# Home directory of JavaCC
javacc.home = .
javacc.zip.dir = ${javacc.home}/lib
javacc.zip = ${javacc.zip.dir}/JavaCC.zip
# Home directory of jakarta-site2
jakarta.site2.home = ../jakarta-site2