Welcome, Simon. I'm sure a number of people are eagerly waiting for your GData
server implementation. I read your project overview. Sounds good. Regarding
the part where you describe how indexing/fields could be configured via XML
descriptors, you may want to have a look at
lucene/java/trun
This sounds reasonable to me. I feel bad about Andi and PyLucene, but it
sounds like GCJ(X) will soon be up-to-date (the link Andi sent was from early
February). Discussion done or?
Otis
- Original Message
From: Chris Hostetter <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent:
I imagine JPackage people monitor places like Lucene:
http://freshmeat.net/projects/lucene/
But if they don't, please add instructions for notifying JPackage folks to
http://wiki.apache.org/jakarta-lucene/ReleaseTodo
Otis
- Original Message
From: DM Smith <[EMAIL PROTECTED]>
To: java-d
[ http://issues.apache.org/jira/browse/LUCENE-550?page=all ]
Otis Gospodnetic updated LUCENE-550:
Attachment: (was: src.tar.gz)
> InstanciatedIndex - faster but memory consuming index
> -
>
>
Done.
- Original Message
From: karl wettin <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Saturday, May 27, 2006 7:45:30 AM
Subject: Att: Jira admins
Please remove all attachment from issue 550 but the following:
4. instanciated_20060527.tar (100 kb)
The images can stay thou
[ http://issues.apache.org/jira/browse/LUCENE-550?page=all ]
Otis Gospodnetic updated LUCENE-550:
Attachment: (was: InstanciatedIndex.java)
> InstanciatedIndex - faster but memory consuming index
>
[ http://issues.apache.org/jira/browse/LUCENE-550?page=all ]
Otis Gospodnetic updated LUCENE-550:
Attachment: (was: src_20060509.tar.gz)
> InstanciatedIndex - faster but memory consuming index
> ---
[ http://issues.apache.org/jira/browse/LUCENE-550?page=all ]
Otis Gospodnetic updated LUCENE-550:
Attachment: (was: src-1.9karl1_20060611.tar.gz)
> InstanciatedIndex - faster but memory consuming index
> --
[ http://issues.apache.org/jira/browse/LUCENE-550?page=all ]
Otis Gospodnetic updated LUCENE-550:
Attachment: (was: Term.java)
> InstanciatedIndex - faster but memory consuming index
> -
>
>
[ http://issues.apache.org/jira/browse/LUCENE-550?page=all ]
Otis Gospodnetic updated LUCENE-550:
Attachment: (was: Document.java)
> InstanciatedIndex - faster but memory consuming index
> -
>
>
[
http://issues.apache.org/jira/browse/LUCENE-551?page=comments#action_12413661 ]
Otis Gospodnetic commented on LUCENE-551:
-
I see the new Lucene 2.0 didn't make it to iBiblio. Please see my previous
comment and questions, so we can take care of th
I do agree with you that subversion would be a kind of an overkill to
include it into the project. I will provied an Interfaces to these
component to change the implementation and / or provide more than one
alternative.
For simplizity I will store the feeds and enties into the index or
create two
[ http://issues.apache.org/jira/browse/LUCENE-578?page=all ]
Simon Willnauer updated LUCENE-578:
---
Attachment: additional_libs.tar.gz
Logging jars
> Summer of Code GDATA Server --Project structure and simple version to start
> with--
> --
[ http://issues.apache.org/jira/browse/LUCENE-578?page=all ]
Simon Willnauer updated LUCENE-578:
---
Attachment: diff_28_05_06.txt
Hey Doug, here is the update for the initial checkin. The diff file contains
all the changes again.
I did modify the toplev
: This is just another push to get the patch committed.
Patches with unit tests demonstrating the problem (and the fix) are more
likely to get attention.
-Hoss
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional comman
If the lazy field loading gets applied (which it should soon), you would
see less of a performance hit for storing items in Lucene, at least when
just getting hits. And you could compress the feeds too
Also, maybe Subversion could act as your repository? I don't know if it
is a viable soluti
[
http://issues.apache.org/jira/browse/LUCENE-575?page=comments#action_12413635 ]
Karl Wettin commented on LUCENE-575:
This is just another push to get the patch committed.
> SpellChecker min score is increased by time
>
Yes and No :) well the problem with the versioning system is still not
solved but I did contact the google developers to get in touch with
them to solve this problem.
I will definately have a look at the BDB JE and will keep it in mind.
I had a quick look at it and it sound quiet suitable for stor
Not sure if Berkeley DB is an option, but it sounds like you just need a
"storage" component for feeds, and BDB JE might be a good fit. I just used it
recently for one such system and was quite happy with performance and ease of
use.
Otis
- Original Message
From: Simon Willnauer <[EM
i haven't gone into this thread in detail, but i simply don't see real
needs for the source to use 1.5 features anytime soon, or if it's
needed at all? as far as i'm concerned is that the existing core is
proven to be fast and stable. will changing the source to using 1.5
language features make
I have added http://wiki.apache.org/jakarta-lucene/LucenePlanning to the
Wiki. Currently there are two items of interest in it. A start of some
documentation related to a Java 1.5 migration and a start of some
documentation concerning how to add more flexible indexing options and
how to store
Hey Paul, while I was writing the proposal for the project I was
considering some CVS/SVN component for the gdata server which is
predestinated for doing such a job. I will startup with the simplest
approach. I will store the entries inside the lucene index as yonik
and chuck have described. Later
On Sunday 28 May 2006 01:33, Simon Willnauer wrote:
> For those who haven't heard about the GData project please check
> today's mailing list .
> The Lucene Indexer is supposed to be used as the search component of
> this implementation. As GData is an extension to the Atom/Rss format
> including
23 matches
Mail list logo
