Why 6.1 should have more bugs than 5.5 ?
6.1 does contain tons of bugfixes and new features.
Of course sperimental features can be buggy, but for the rest I would go
with 6.1 ( which is 5.5 more mature )
If you don't like 6.x you can go with 5.5.2 which have bugfixes backported.
Cheers
On Thu, Ju
Hi,
is there any documentation page that outlines the PROS and CONS about
whether to use 5.5 or 6.1?
I'm using Java 1.8 so 6.1 might be the right choice, however I believe that
6.x is still quite fresh and might have more bugs than the more matured 5.5?
Thanks
Bas
Well, I solved the problem on my own.
I didn't find anything because it was a conflict between package's
dependencies.
Thanks anyway! (and make sure all you Lucene's packages have the same
version in your Maven configuration)
Anna
On Wed, Jun 29, 2016 at 7:01 PM, Anna Berruezo wrote:
> Hi,
>
Thanks for the quick reply Uwe!
I opened https://issues.apache.org/jira/browse/LUCENE-7366 for this.
-Rob
On Thu, Jun 30, 2016 at 12:06 PM, Uwe Schindler wrote:
> Hi,
>
> I looked at the code: The FSDirectory passed to RAMDirectory could be
> changed to Directory easily. The additional check f
Hi,
I'm observing below issue while getting instance of indexWriter after releasing
searcher from searcherManager
java.lang.IllegalArgumentException: Directory
MMapDirectory@C:\work\egain\eService\index\ARTICLE_201606160754
lockFactory=org.apache.lucene.store.NativeFSLockFactory@1ec79746 still
Hi,
I looked at the code: The FSDirectory passed to RAMDirectory could be changed
to Directory easily. The additional check for "not is a directory inode" is in
my opinion lo longer needed, because listFiles should only return files.
Can you open an issue about to change the FSDirectory in the
Hi all,
For increasing the speed of some of my application tests, I want to
re-use/copy a pre-populated RAMDirectory over and over.
I'm on Lucene 6.0.1
It seems an RAMDirectory can be a copy of a FSDirectory, but not of another
RAMDirectory. Also RAMDirectory is not Clonable.
What would be the
