You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@poi.apache.org by "Andrew C. Oliver" <ac...@apache.org> on 2003/02/03 15:24:17 UTC
Please help (esp for Glen :-) )[Fwd: [DRAFT1] Jakarta Newsletter
- January 2003]
-------- Original Message --------
Subject: [DRAFT1] Jakarta Newsletter - January 2003
Date: Sun, 02 Feb 2003 23:59:28 +0000
From: "Rob Oxspring" <ro...@apache.org>
Reply-To: "Jakarta General List" <ge...@jakarta.apache.org>
To: "Jakarta General List" <ge...@jakarta.apache.org>
Jakarta Newsletter
==================
Issue: 7
Date: January 2003
Url: http://jakarta.apache.org/site/news/200301.html
TODO
Contents
--------
General
Lucene
General
=======
" Ideas, suggestions, and comments on the overall Jakarta project "
Editor: Rob Oxspring
Robert Simmons kicked of a debate over the use of forum software to make
it easier for users to get involved with jakarta subprojects [1,2]. The
Jakarta developers seemed united in preferring mailing lists and pointed
out archives [3] and services such as gmane [4] for more casual use of
the lists.
The Pluto subproject was proposed as a reference implementation of the
Portlet API and was heavily discussed [5]. Relating to the portals theme,
Charon was propsed ro implement the Web Services for Remote
specification, although this recieved only a little discussion [6,7].
Dani Estermann asked for some advice on choosing a logging stratergy for
future code. Some advocated using the JDK logging if Java 1.4 was
guarenteed, others recommended using Log4j whatever the situation. It was
also suggested that the use of a facade such as commons-logging should be
limitted to situations where chioce is needed. Browse the archive for
further detail [8].
Is it time for a new look Jakarta? Maybe a unified Apache site look and
feel? Christoph Wilhelms suggested the use of his FakeForrest skin to
give Jakarta a facelift [9]. This offers a Forrest[10] look a like and
could act as a stepping stone towards the eventual use of forrest for the
websites.
[1] -
http://archives.apache.org/eyebrowse/BrowseList?listName=general@jakarta.apache.org&by=thread&from=305266
[2] -
http://archives.apache.org/eyebrowse/BrowseList?listName=general@jakarta.apache.org&by=thread&from=309508
[3] - http://archives.apache.org/eyebrowse/
[4] - http://www.gmane.org/
[5] -
http://archives.apache.org/eyebrowse/BrowseList?listName=general@jakarta.apache.org&by=thread&from=308677
[6] -
http://archives.apache.org/eyebrowse/BrowseList?listName=general@jakarta.apache.org&by=thread&from=308715
[7] -
http://archives.apache.org/eyebrowse/BrowseList?listName=general@jakarta.apache.org&by=thread&from=308716
[8] -
http://archives.apache.org/eyebrowse/BrowseList?listName=general@jakarta.apache.org&by=thread&from=314971
[9] -
http://archives.apache.org/eyebrowse/BrowseList?listName=general@jakarta.apache.org&by=thread&from=315699
[10] - http://xml.apache.org/forrest/
Lucene
======
" A high-performance, full-featured text search engine "
Editor: Otis Gospodnetic
This month's notes come straight from Lucene's CHANGES.txt file. In
addition to that I'll only mention that the Lucene team is preparing for
packaging the first release candidate for the 1.3 release.
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.
g. Added public accessors to the primitive query classes (TermQuery,
PhraseQuery and BooleanQuery), permitting access to their terms and
clauses.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Please help (esp for Glen :-) )[Fwd: [DRAFT1] Jakarta
Newsletter
Posted by Glen Stampoultzis <gs...@iprimus.com.au>.
Will do
At 09:24 AM 3/02/2003 -0500, you wrote:
>-------- Original Message --------
>Subject: [DRAFT1] Jakarta Newsletter - January 2003
>Date: Sun, 02 Feb 2003 23:59:28 +0000
>From: "Rob Oxspring" <ro...@apache.org>
>Reply-To: "Jakarta General List" <ge...@jakarta.apache.org>
>To: "Jakarta General List" <ge...@jakarta.apache.org>
>
>Jakarta Newsletter
>==================
>
>Issue: 7
>Date: January 2003
>Url: http://jakarta.apache.org/site/news/200301.html
>
>TODO
>
>Contents
>--------
>
>General
>Lucene
>
>
>
>General
>=======
>" Ideas, suggestions, and comments on the overall Jakarta project "
>Editor: Rob Oxspring
>
>Robert Simmons kicked of a debate over the use of forum software to make
>it easier for users to get involved with jakarta subprojects [1,2]. The
>Jakarta developers seemed united in preferring mailing lists and pointed
>out archives [3] and services such as gmane [4] for more casual use of
>the lists.
>
>The Pluto subproject was proposed as a reference implementation of the
>Portlet API and was heavily discussed [5]. Relating to the portals theme,
>Charon was propsed ro implement the Web Services for Remote
>specification, although this recieved only a little discussion [6,7].
>
>Dani Estermann asked for some advice on choosing a logging stratergy for
>future code. Some advocated using the JDK logging if Java 1.4 was
>guarenteed, others recommended using Log4j whatever the situation. It was
>also suggested that the use of a facade such as commons-logging should be
>limitted to situations where chioce is needed. Browse the archive for
>further detail [8].
>
>Is it time for a new look Jakarta? Maybe a unified Apache site look and
>feel? Christoph Wilhelms suggested the use of his FakeForrest skin to
>give Jakarta a facelift [9]. This offers a Forrest[10] look a like and
>could act as a stepping stone towards the eventual use of forrest for the
>websites.
>
>[1] -
>http://archives.apache.org/eyebrowse/BrowseList?listName=general@jakarta.apache.org&by=thread&from=305266
>[2] -
>http://archives.apache.org/eyebrowse/BrowseList?listName=general@jakarta.apache.org&by=thread&from=309508
>[3] - http://archives.apache.org/eyebrowse/
>[4] - http://www.gmane.org/
>[5] -
>http://archives.apache.org/eyebrowse/BrowseList?listName=general@jakarta.apache.org&by=thread&from=308677
>[6] -
>http://archives.apache.org/eyebrowse/BrowseList?listName=general@jakarta.apache.org&by=thread&from=308715
>[7] -
>http://archives.apache.org/eyebrowse/BrowseList?listName=general@jakarta.apache.org&by=thread&from=308716
>[8] -
>http://archives.apache.org/eyebrowse/BrowseList?listName=general@jakarta.apache.org&by=thread&from=314971
>[9] -
>http://archives.apache.org/eyebrowse/BrowseList?listName=general@jakarta.apache.org&by=thread&from=315699
>[10] - http://xml.apache.org/forrest/
>
>
>
>Lucene
>======
>" A high-performance, full-featured text search engine "
>Editor: Otis Gospodnetic
>
>This month's notes come straight from Lucene's CHANGES.txt file. In
>addition to that I'll only mention that the Lucene team is preparing for
>packaging the first release candidate for the 1.3 release.
>
>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.
>
>g. Added public accessors to the primitive query classes (TermQuery,
>PhraseQuery and BooleanQuery), permitting access to their terms and
>clauses.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: general-help@jakarta.apache.org
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: poi-dev-help@jakarta.apache.org