Re: [JENKINS] Lucene-main-Linux (64bit/jdk-16) - Build # 31986 - Unstable!

[Patrick Zhai]

My bad, I should have added 1 to the alphabet size, I assumed it was
exclusive.

Here's PR fixing it: https://github.com/apache/lucene/pull/559

Policeman Jenkins Server  于2021年12月20日周一 21:34写道：

> Build: https://jenkins.thetaphi.de/job/Lucene-main-Linux/31986/
> Java: 64bit/jdk-16 -XX:-UseCompressedOops -XX:+UseSerialGC
>
> 1 tests failed.
> FAILED:
> org.apache.lucene.util.automaton.TestNFARunAutomaton.testWithRandomRegex
>
> Error Message:
> java.lang.AssertionError
>
> Stack Trace:
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([75637BDB16D0FDF0:1030A407D690701]:0)
> at
> org.apache.lucene.util.automaton.NFARunAutomaton.getCharClass(NFARunAutomaton.java:161)
> at
> org.apache.lucene.util.automaton.NFARunAutomaton.step(NFARunAutomaton.java:133)
> at
> org.apache.lucene.util.automaton.NFARunAutomaton.step(NFARunAutomaton.java:98)
> at
> org.apache.lucene.util.automaton.NFARunAutomaton.run(NFARunAutomaton.java:121)
> at
> org.apache.lucene.util.automaton.TestNFARunAutomaton.testAcceptedString(TestNFARunAutomaton.java:161)
> at
> org.apache.lucene.util.automaton.TestNFARunAutomaton.testWithRandomRegex(TestNFARunAutomaton.java:70)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1754)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:942)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:978)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:992)
> at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:44)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43)
> at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:45)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:60)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:44)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:370)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:819)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:470)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:951)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:836)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:887)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:898)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:44)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:60)
> at
> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:47)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at
> 

Re: Welcome Haoyu (Patrick) Zhai as Lucene Committer

[Michael Gibney]

Congratulations, and welcome!
Michael

On Mon, Dec 20, 2021 at 1:17 PM Steve Rowe  wrote:

> Congrats and welcome, Patrick!
>
> —
> Steve
>
> > On Dec 19, 2021, at 4:11 AM, Dawid Weiss  wrote:
> >
> > Hello everyone!
> >
> > Please welcome Haoyu Zhai as the latest Lucene committer. You may also
> > know Haoyu as Patrick - this is perhaps his kind gesture to those of
> > us whose tongues are less flexible in pronouncing difficult first
> > names. :)
> >
> > It's a tradition to briefly introduce yourself to the group, Patrick.
> > Welcome and thank you!
> >
> > Dawid
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [Heads up] Test framework package rename

[Dawid Weiss]

> You are correct (you’re safe). Lucene has bumped the minimum JDK
> to 17, right? If so, you could use MethodHandles.Lookup::ensureInitialized.

It'll probably go into the 9x branch which will remain on older JDKs. That
Class.forName trick is so simple and straightforward that I think I'm going to
stick to it for now.

> Nothing specific, just that if we’re injecting code into the module
> (patching the module for unit testing purposes), then even the secrets
> (currently in the product code), could be effectively injected too.

Right, I get you now. Yes - indeed it could be completely separate but then
everyone using the test framework module (it is published as part of
Lucene artifacts)
would have to remember and somehow apply the patch options... I'd
rather just go for
simplicity here - if you require the lucene framework module, it'll
just work, no
patching needed. As much as I like playing with the jms, the effort
required to get the
tools to a reasonably working state is still significant.

> I was mostly thinking of how the IDE would react to —-patch-module, and
> whether or not it could handle things like auto-complete, etc, from
> consuming code whose view point just sees the patched module as one
> complete unit.

I doubt it'll work the way you describe it. But hey, it's Christmas
time - excellent
time for good wishes. ;)

D.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Haoyu (Patrick) Zhai as Lucene Committer

[Steve Rowe]

Congrats and welcome, Patrick!

—
Steve

> On Dec 19, 2021, at 4:11 AM, Dawid Weiss  wrote:
> 
> Hello everyone!
> 
> Please welcome Haoyu Zhai as the latest Lucene committer. You may also
> know Haoyu as Patrick - this is perhaps his kind gesture to those of
> us whose tongues are less flexible in pronouncing difficult first
> names. :)
> 
> It's a tradition to briefly introduce yourself to the group, Patrick.
> Welcome and thank you!
> 
> Dawid
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Haoyu (Patrick) Zhai as Lucene Committer

[Houston Putman]

Congrats Haoyu!

On Mon, Dec 20, 2021 at 12:42 PM Anshum Gupta 
wrote:

> Congratulations and welcome, Haoyu!
>
> On Sun, Dec 19, 2021 at 1:12 AM Dawid Weiss  wrote:
>
>> Hello everyone!
>>
>> Please welcome Haoyu Zhai as the latest Lucene committer. You may also
>> know Haoyu as Patrick - this is perhaps his kind gesture to those of
>> us whose tongues are less flexible in pronouncing difficult first
>> names. :)
>>
>> It's a tradition to briefly introduce yourself to the group, Patrick.
>> Welcome and thank you!
>>
>> Dawid
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
> --
> Anshum Gupta
>

Re: [Heads up] Test framework package rename

[Chris Hegarty]

Hi David,

> On 20 Dec 2021, at 17:12, Dawid Weiss  wrote:
> 
> [snip]
> 
>> I think that the approach is reasonable (to inject ’test’ into the package 
>> name between the reverse DNS prefix and the specific logical technology 
>> suffix).
> 
> It's actually '.tests'... Robert (Muir) suggested .test as well but I
> must have added that extra 's' somewhere along the line and I didn't
> have the heart to redo all the refactorings...

Ah yes, '.tests’ - which is also fine.

> [ snip ]
>> TestSecrets also seems reasonable. It’s a pity that it intrudes somewhat on 
>> the actual product code, but not to any extent that would be concerning.
> 
> This is quite funny - I actually reengineered the internal-package
> trick, although my version looked slightly different (it had public
> methods returning the "secret" accessors, although they couldn't be
> instantiated by anything else than the internal package - you can see
> it in the commit history... then I recalled that the JDK had a similar
> solution and peeked at how that was done. I thought it was nicer as it
> didn't pollute the API.

Right, if you need access to package-privates from an “API” package, 
then secrets are a fine tool for the job.

> So now you know whom I borrowed the idea from
> - you. :)
> 
> The only difference is the use of unsafe to make sure classes have
> their static blocks invoked. I didn't want to bring unsafe into the
> mix and used Class.forName(apiClazz.getName()). I don't think this can
> have any side-effects whatsoever and the contract on this variant of
> forName has the initialization flag on, so it seems to be safe -
> correct me if I'm wrong though.

You are correct (you’re safe). Lucene has bumped the minimum JDK
to 17, right? If so, you could use MethodHandles.Lookup::ensureInitialized.
Or this could be done separately, if there is interest. (hmm.. maybe you
don’t wanna go down this rabbit hole now!, lookup access could be an
issue )

>> It’s great that you can now have a test_framework module. And, from what I 
>> can see, the moduleXXX configurations that you introduced recently work just 
>> fine for the Gradle dependency configuration.
> 
> I have to admit this works rather nicely. There are some rough corners
> we discovered already but I think they're all fixable with relative
> easy -
> https://issues.apache.org/jira/browse/LUCENE-10328
> 
> I'm sure in the end this could be extracted into a more reusable
> gradle plugin, probably replacing the built-in support for modules,
> but for the time being it's just easier to work with those separate
> gradle scripts.

Yeah, it seems so.

>> Once this is in, then it will be possible to patch area specific unit tests 
>> into the actual product module and `require` the framework, right?
> 
> Yes, I think this is doable. It's what Uwe has been asking for - his
> panama branch currently requires tricks that shouldn't be there.

Ok, great. I think we’re on the same track.

>> And if we had that, it’s not a big leap to maybe refactor some of the 
>> secrets to be injected too ( but I accept that that is not really necessary 
>> either, and I’m not sure how the IDEs or Gradle would like this )
> 
> What secrets do you have in mind here?

Nothing specific, just that if we’re injecting code into the module
(patching the module for unit testing purposes), then even the secrets
(currently in the product code), could be effectively injected too.
(The code that sets things up in the API packages). Almost as if each
module had its own mini-test-framework, which could be (but does not
strictly need to be) part of its unit test. 

> As for IDEs: IntelliJ should
> work fine as it converts each source set into a logical dependency
> unit. I don't think how Eclipse can be made to digest all this - for
> now, we create a big bag of sources without submodule demarcation. So
> it compiles, although is far from ideal.

I was mostly thinking of how the IDE would react to —-patch-module, and
whether or not it could handle things like auto-complete, etc, from
consuming code whose view point just sees the patched module as one
complete unit. 

Anyway, that is a distraction from the good work here, and something for
another day.

-Chris.



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Haoyu (Patrick) Zhai as Lucene Committer

[Anshum Gupta]

Congratulations and welcome, Haoyu!

On Sun, Dec 19, 2021 at 1:12 AM Dawid Weiss  wrote:

> Hello everyone!
>
> Please welcome Haoyu Zhai as the latest Lucene committer. You may also
> know Haoyu as Patrick - this is perhaps his kind gesture to those of
> us whose tongues are less flexible in pronouncing difficult first
> names. :)
>
> It's a tradition to briefly introduce yourself to the group, Patrick.
> Welcome and thank you!
>
> Dawid
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Anshum Gupta

Re: [Heads up] Test framework package rename

[Dawid Weiss]

Hi Chris!

> [ not a review ]

[feedback is always welcome, especially from you]

> I think that the approach is reasonable (to inject ’test’ into the package 
> name between the reverse DNS prefix and the specific logical technology 
> suffix).

It's actually '.tests'... Robert (Muir) suggested .test as well but I
must have added that extra 's' somewhere along the line and I didn't
have the heart to redo all the refactorings...

> I’ve played a little with similar in the Elasticsearch codebase - but not yet 
> advanced it to a point that eliminates all split packages.

ES is much larger and more complex, so I'm not surprised. Same like
Solr. Lucene is relatively simple -- lots of code but all of the
modules are fairly simple structure-wise. Makes such experiments more
approachable.

> TestSecrets also seems reasonable. It’s a pity that it intrudes somewhat on 
> the actual product code, but not to any extent that would be concerning.

This is quite funny - I actually reengineered the internal-package
trick, although my version looked slightly different (it had public
methods returning the "secret" accessors, although they couldn't be
instantiated by anything else than the internal package - you can see
it in the commit history... then I recalled that the JDK had a similar
solution and peeked at how that was done. I thought it was nicer as it
didn't pollute the API. So now you know whom I borrowed the idea from
- you. :)

The only difference is the use of unsafe to make sure classes have
their static blocks invoked. I didn't want to bring unsafe into the
mix and used Class.forName(apiClazz.getName()). I don't think this can
have any side-effects whatsoever and the contract on this variant of
forName has the initialization flag on, so it seems to be safe -
correct me if I'm wrong though.

> It’s great that you can now have a test_framework module. And, from what I 
> can see, the moduleXXX configurations that you introduced recently work just 
> fine for the Gradle dependency configuration.

I have to admit this works rather nicely. There are some rough corners
we discovered already but I think they're all fixable with relative
easy -
https://issues.apache.org/jira/browse/LUCENE-10328

I'm sure in the end this could be extracted into a more reusable
gradle plugin, probably replacing the built-in support for modules,
but for the time being it's just easier to work with those separate
gradle scripts.

> Once this is in, then it will be possible to patch area specific unit tests 
> into the actual product module and `require` the framework, right?

Yes, I think this is doable. It's what Uwe has been asking for - his
panama branch currently requires tricks that shouldn't be there.

> And if we had that, it’s not a big leap to maybe refactor some of the secrets 
> to be injected too ( but I accept that that is not really necessary either, 
> and I’m not sure how the IDEs or Gradle would like this )

What secrets do you have in mind here? As for IDEs: IntelliJ should
work fine as it converts each source set into a logical dependency
unit. I don't think how Eclipse can be made to digest all this - for
now, we create a big bag of sources without submodule demarcation. So
it compiles, although is far from ideal.

Dawid

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [Heads up] Test framework package rename

[Chris Hegarty]

Hi David,

[ not a review ]

> On 20 Dec 2021, at 14:54, Dawid Weiss  wrote:
> 
> 
> Hello everyone,
> 
> I've completed the task of getting the test framework to not share any 
> packages with Lucene core - this is here:
> 
> https://issues.apache.org/jira/browse/LUCENE-10301 
> 
> https://github.com/apache/lucene/pull/551 
> 
> 
> Basically everything remains the same, except for the changed package prefix. 
> The patch is rather large because it cuts across all of the code (imports, 
> mostly). There are also some minor tweaks to expose package-private internals 
> in the core to the test framework, now residing in a different package.


I think that the approach is reasonable (to inject ’test’ into the package name 
between the reverse DNS prefix and the specific logical technology suffix). 
I’ve played a little with similar in the Elasticsearch codebase - but not yet 
advanced it to a point that eliminates all split packages.

TestSecrets also seems reasonable. It’s a pity that it intrudes somewhat on the 
actual product code, but not to any extent that would be concerning.

It’s great that you can now have a test_framework module. And, from what I can 
see, the moduleXXX configurations that you introduced recently work just fine 
for the Gradle dependency configuration. ( I wish that we were at a similar 
point in ES, but recent distractions have slowed progress :-( )

Once this is in, then it will be possible to patch area specific unit tests 
into the actual product module and `require` the framework, right? And if we 
had that, it’s not a big leap to maybe refactor some of the secrets to be 
injected too ( but I accept that that is not really necessary either, and I’m 
not sure how the IDEs or Gradle would like this )

-Chris. 

Re: Welcome Haoyu (Patrick) Zhai as Lucene Committer

[Greg Miller]

Congrats and welcome!

On Mon, Dec 20, 2021 at 6:08 AM Jan Høydahl  wrote:
>
> Welcome Patrick!
>
> Jan
>
> 19. des. 2021 kl. 10:11 skrev Dawid Weiss :
>
> Hello everyone!
>
> Please welcome Haoyu Zhai as the latest Lucene committer. You may also
> know Haoyu as Patrick - this is perhaps his kind gesture to those of
> us whose tongues are less flexible in pronouncing difficult first
> names. :)
>
> It's a tradition to briefly introduce yourself to the group, Patrick.
> Welcome and thank you!
>
> Dawid
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [Heads up] Test framework package rename

[Dawid Weiss]

> large that it makes the Github UI unresponsive, so I'll review the
> diff locally while check runs.
>

Right - I did the same, actually. You can grep/throw away most of the lines
that have imports in them as these are irrelevant.

D.

Re: [Heads up] Test framework package rename

[Robert Muir]

Thanks for doing this!! Give me a few minutes, I'll verify everything
passes on linux, and review it locally. And I agree, sooner than later
is better as it will conflict with anything and everything.

Due to the expected noise of the import statements, the change is so
large that it makes the Github UI unresponsive, so I'll review the
diff locally while check runs.

On Mon, Dec 20, 2021 at 9:55 AM Dawid Weiss  wrote:
>
>
> Hello everyone,
>
> I've completed the task of getting the test framework to not share any 
> packages with Lucene core - this is here:
>
> https://issues.apache.org/jira/browse/LUCENE-10301
> https://github.com/apache/lucene/pull/551
>
> Basically everything remains the same, except for the changed package prefix. 
> The patch is rather large because it cuts across all of the code (imports, 
> mostly). There are also some minor tweaks to expose package-private internals 
> in the core to the test framework, now residing in a different package.
>
> Tests pass for me but I could use a pair of eyes on the patch. This will be 
> rather annoying for backports (if you change anything in the test framework 
> itself) so I'd like to apply it to 9x and main. Soon-ish, if there are no 
> objections.
>
> Dawid

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[Heads up] Test framework package rename

[Dawid Weiss]

Hello everyone,

I've completed the task of getting the test framework to not share any
packages with Lucene core - this is here:

https://issues.apache.org/jira/browse/LUCENE-10301
https://github.com/apache/lucene/pull/551

Basically everything remains the same, except for the changed package
prefix. The patch is rather large because it cuts across all of the code
(imports, mostly). There are also some minor tweaks to expose
package-private internals in the core to the test framework, now residing
in a different package.

Tests pass for me but I could use a pair of eyes on the patch. This will be
rather annoying for backports (if you change anything in the test framework
itself) so I'd like to apply it to 9x and main. Soon-ish, if there are no
objections.

Dawid

Re: Welcome Haoyu (Patrick) Zhai as Lucene Committer

[Jan Høydahl]

Welcome Patrick!

Jan

> 19. des. 2021 kl. 10:11 skrev Dawid Weiss :
> 
> Hello everyone!
> 
> Please welcome Haoyu Zhai as the latest Lucene committer. You may also
> know Haoyu as Patrick - this is perhaps his kind gesture to those of
> us whose tongues are less flexible in pronouncing difficult first
> names. :)
> 
> It's a tradition to briefly introduce yourself to the group, Patrick.
> Welcome and thank you!
> 
> Dawid
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

Searching Lucene FAQ with Lucene

[Michael Wechner]

Hi

I am working on a webapp called "Katie" in order to detect duplicated 
questions


https://ukatie.com/

As a test case I have imported the Lucene FAQ

https://cwiki.apache.org/confluence/display/LUCENE/LuceneFAQ

to

https://ukatie.com/#/faq/9f206aec-5223-4e03-a2fc-c16e4b885ef8/en

and made them available at

https://lucene-faq.ukatie.com/

whereas the FAQ are loaded as JSON from the REST interface of Katie

https://ukatie.com/swagger-ui/?urls.primaryName=API%20V2#/faq-controller-v-2/getFAQUsingGET_1

and the Javascript can be found at

https://github.com/wyona/katie-4-faq

I am currently "experimenting" with different search algorithms, e.g.

Lucene only
SentenceBERT- Lucene Vector Search
SentenceBERT only
Weaviate

The goal is to find the right answer with "similar" questions, e.g.

- "Are there mailing lists?"
- "How can I ask questions re Lucene?"

independent whether the question was trained/indexed or not or the 
answer contains keywords of the question


whereas the answer in this particular case is

https://ukatie.com/#/read-answer?domain-id=9f206aec-5223-4e03-a2fc-c16e4b885ef8=e19b6f48-62ac-427a-9d5e-d4e4eb110769

and another meaningful answer could be

https://ukatie.com/#/read-answer?domain-id=9f206aec-5223-4e03-a2fc-c16e4b885ef8=154d9aa7-29e6-457e-a2ad-315b1a67599f

There is still a lot to be improved :-) but it is lot of fun to use 
Lucene for this!


Any feedback is very welcome or if you want to know more about the 
implementation details.


Thanks

Michael



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org