I will take care of the file formats issue. I thought I updated
before committing, but I obviously missed it.
I would like to move the rest of this discussion to http://
issues.apache.org/jira/browse/LUCENE-708 so it is captured on the
issue, so look for a message from that issue shortly.
[
http://issues.apache.org/jira/browse/LUCENE-708?page=comments#action_12454308 ]
Grant Ingersoll commented on LUCENE-708:
I am working on the nightly build stuff, etc. My plan is to start hosting
versions under the "Site Versions" sect
[
http://issues.apache.org/jira/browse/LUCENE-708?page=comments#action_12454375 ]
Doron Cohen commented on LUCENE-708:
Could "official" be the most recent release (currently 2.0)?
So there would be:
Official (2.0)
Nightly
1.9.1
1.9
1.4
Use DateTools instead of deprecated DateField in QueryParser
Key: LUCENE-732
URL: http://issues.apache.org/jira/browse/LUCENE-732
Project: Lucene - Java
Issue Type: Improvement
[ http://issues.apache.org/jira/browse/LUCENE-732?page=all ]
Michael Busch updated LUCENE-732:
-
Attachment: queryparser_datetools.patch
> Use DateTools instead of deprecated DateField in QueryParser
> -
[
http://issues.apache.org/jira/browse/LUCENE-708?page=comments#action_12454427 ]
Doug Cutting commented on LUCENE-708:
-
According to Apache policy, nightly builds must not be easily confused with
releases.
http://www.apache.org/dev/release
[ http://issues.apache.org/jira/browse/LUCENE-707?page=all ]
Daniel Naber reopened LUCENE-707:
-
The link to the image (asf-logo.gif) in the upper left corner is broken (mhh,
same problem at Nutch site).
> Lucene Java Site docs
> -
problems with some non word ascii characters in searchs
---
Key: LUCENE-733
URL: http://issues.apache.org/jira/browse/LUCENE-733
Project: Lucene - Java
Issue Type: Bug
Components:
Attached are proposed modifications to Lucene 2.0 to support
Field.Store.Encrypted.
The rational behind this proposal is simple. Since Lucene can store data in
the index, it effectively makes the data portable. It is conceivable that
some of the data may be sensitive in nature, hence the option to
[
http://issues.apache.org/jira/browse/LUCENE-707?page=comments#action_12454439 ]
Grant Ingersoll commented on LUCENE-707:
Do you mean the feather logo and how it points to lucene.apache.org instead of
apache.org?
This is a placeholde
Hi Yonik,
Thanks for your comments.
Secondly, has anyone thought that it would be a good idea to extend
the Analyzer
interface (Abstract class) to allow a standard way to set stop words?
There
seem to be two 'families' of stop word configuration via constructors.
That belongs at the TokenF
[
http://issues.apache.org/jira/browse/LUCENE-732?page=comments#action_12454449 ]
Daniel Naber commented on LUCENE-732:
-
I'm not sure if most people use DateTools already, as it has just been added in
Lucene 1.9. Maybe you could consider an
On 11/29/06, Antony Bowesman <[EMAIL PROTECTED]> wrote:
>> seem to be two 'families' of stop word configuration via constructors.
>
> That belongs at the TokenFilter level (where it currently is).
That's true, but all the existing Analyzers allow the stop set to be configured
via the analyzer co
[
http://issues.apache.org/jira/browse/LUCENE-708?page=comments#action_12454453 ]
Grant Ingersoll commented on LUCENE-708:
Doug,
How about I take the nightly build and source download off of
http://lucene.apache.org/java/docs/releases.h
[ http://issues.apache.org/jira/browse/LUCENE-708?page=all ]
Grant Ingersoll updated LUCENE-708:
---
Comment: was deleted
> Setup nightly build website links and docs
> --
>
> Key: LUCENE-708
>
[
http://issues.apache.org/jira/browse/LUCENE-707?page=comments#action_12454454 ]
Hoss Man commented on LUCENE-707:
-
I believe the old version of the site had the feather there linking up to the
top level Lucene website ... might want to put it
[
http://issues.apache.org/jira/browse/LUCENE-732?page=comments#action_12454457 ]
Hoss Man commented on LUCENE-732:
-
cleanest way to be backwards compatible would be to not have an initial default
Resolution, and use DateField if no Resolution c
On Nov 29, 2006, at 8:47 AM, Grant Ingersoll wrote:
I will take care of the file formats issue. I thought I updated
before committing, but I obviously missed it.
Done.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For addit
[
http://issues.apache.org/jira/browse/LUCENE-708?page=comments#action_12454463 ]
Hoss Man commented on LUCENE-708:
-
maybe there is some confusion as to the purpose of this issue ... i was under
the impression that Grant's primary goal was to ma
[
http://issues.apache.org/jira/browse/LUCENE-732?page=comments#action_12454469 ]
Michael Busch commented on LUCENE-732:
--
Actually it is documented in the QueryParser how to use a different format for
dates:
...
* feature also assum
Nightly -> "./"
Stable (2.0) -> "../2.0-docs/"
1.9.1 -> "../1.9.1-docs"
1.9 -> "../1.9-docs"
1.4.3 -> "../14.3-docs"
+1
This was my intent, but you said it better. Additionally, I think
the Nightly can be updated adhoc, too when a committer deems prudent,
as is often done when upd
: This was my intent, but you said it better. Additionally, I think
: the Nightly can be updated adhoc, too when a committer deems prudent,
: as is often done when updating whoweare.html, etc.
It certainly could be if needed for an urgent or specific reason, but
ideally it would just happen magi
[
http://issues.apache.org/jira/browse/LUCENE-669?page=comments#action_12454488 ]
Michael McCandless commented on LUCENE-669:
---
Ugh! This bug is clearly a heisenbug.
OK, I can also reproduce this on Windows when I use the IBM 1.5.0 JRE
Yeah, that is reasonable.
I have taken the liberty of putting up the old sites, although they
aren't linked from anywhere
http://lucene.apache.org/java/docs/2_0_0/
http://lucene.apache.org/java/docs/1_4_3/
http://lucene.apache.org/java/docs/1_9_0/
http://lucene.apache.org/java/docs/1_9_1/
Al
>
> >
> > Nightly -> "./"
> > Stable (2.0) -> "../2.0-docs/"
> > 1.9.1 -> "../1.9.1-docs"
> > 1.9 -> "../1.9-docs"
> > 1.4.3 -> "../14.3-docs"
> >
>
> +1
Convinced me too.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For add
: http://lucene.apache.org/java/docs/2_0_0/
: http://lucene.apache.org/java/docs/1_4_3/
: http://lucene.apache.org/java/docs/1_9_0/
: http://lucene.apache.org/java/docs/1_9_1/
i would advise against that specific directory structure, it may makes it
hard to "refresh" the "current" directory witho
[ http://issues.apache.org/jira/browse/LUCENE-669?page=all ]
Michael McCandless resolved LUCENE-669.
---
Fix Version/s: 2.1
Resolution: Fixed
> finalize()-methods of FSDirectory.FSIndexInput and FSDirectory.FSIndexOutput
> try to close already
[
http://issues.apache.org/jira/browse/LUCENE-669?page=comments#action_12454505 ]
Michael Busch commented on LUCENE-669:
--
Wow that was a tough one!
Thanks for trying so hard to reproduce it, Mike. And thanks for committing, the
small chang
Good point, now at:
http://lucene.apache.org/java/1_4_3/
etc...
but it may take a little while to show up.
So
/www/lucene.apache.org/java/docs contains the live site
/www/lucene.apache.org/java/1_4_3 contains release 1_4_3
and so on
I wasn't sure how these would get added to the server, but it s
I think that adding encryption support to Lucene fields is a bad idea for
the same reasons adding compression was a bad idea (conclusive comments on
the tail of this issue
http://issues.apache.org/jira/browse/LUCENE-648?page=all). Binary fields
can be used by users to achieve this end. Maybe a
Yonik Seeley wrote:
On 11/29/06, Antony Bowesman <[EMAIL PROTECTED]> wrote:
That's true, but all the existing Analyzers allow the stop set to be
configured
via the analyzer constructors, but in different ways.
But you can duplicate most Analyzers (all the ones in Lucene?) with a
chain of To
Thank you Luke for your comments and the references you supplied. I read
through them and reached the following conclusions. There seems to be a
philosophical issue about the boundary between a user application and the
Lucene API, where should one start and the other stop.
The other issue is the s
On 11/29/06, Antony Bowesman <[EMAIL PROTECTED]> wrote:
Yonik Seeley wrote:
> On 11/29/06, Antony Bowesman <[EMAIL PROTECTED]> wrote:
>>
>> That's true, but all the existing Analyzers allow the stop set to be
>> configured
>> via the analyzer constructors, but in different ways.
>
> But you can d
On 11/29/06, Yonik Seeley <[EMAIL PROTECTED]> wrote:
If I were to analyze greek text, I might do something like this:
xt"/>
Hmm, I just discovered that the Porter2 snowball stemmers don't support greek.
Here is the relevant
Yonik Seeley wrote:
On 11/29/06, Antony Bowesman <[EMAIL PROTECTED]> wrote:
Yonik Seeley wrote:
The GreekAnalyzer is just an example of how you can use existing
Analyzers (as long as they have a default constructor), but it's not
the recommended approach.
TokenFilters are preffered over Analy
: Something seems confused to me. Although stop words are use by Filters, they
: are currently exposed via Analyzers which is the granularity used at the
: IndexWriter/Parser levels. This is what contributors are writing, not
Filters.
that's not really true .. if you look at the various contri
36 matches
Mail list logo
