Re: Please help (esp for Glen :-) )[Fwd: [DRAFT1] Jakarta Newsletter

[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