lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Digy (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENENET-345) [Contrib] Extensions
Date Mon, 01 Mar 2010 18:44:06 GMT

    [ https://issues.apache.org/jira/browse/LUCENENET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839797#action_12839797
] 

Digy commented on LUCENENET-345:
--------------------------------

bq. Great to see you are have a few items for the contrib section as well!
https://issues.apache.org/jira/browse/LUCENENET-342

bq. My thought is that many of the small items in contrib such as analyzers, filters - items
that consist of no more than a few classes and their respective tests - be combined into one
project. Larger pieces of functionality such as the highlighter would remain in their respective
projects.
Since Lucene.Net lacks good documentation, people could  find the necessary package (or search
for contribs ported)  easily if we kept the same structure. On the other hand, we can can
gather all Lucene.Net specifics codes under a single project and have a global solution that
compiles all contribs and their test cases.

bq. Perhaps we should combine our two contributions into one project?
Under which name? Just looking at its name, will people know that it is a port from Java(
or Lucene.Net specific code)?



DIGY


> [Contrib] Extensions
> --------------------
>
>                 Key: LUCENENET-345
>                 URL: https://issues.apache.org/jira/browse/LUCENENET-345
>             Project: Lucene.Net
>          Issue Type: New Feature
>            Reporter: Michael Garski
>         Attachments: LUCENENET-345 Extensions.patch, LUCENENET-345 V2.patch, Queries.Net.rar
>
>
> I have created a few generic extensions to Lucene.Net that I use quiet a bit.  It's packaged
up as a VS2008 solution with two projects.  The test project is a Visual Studio test project
as opposed to NUnit, and that can be changed.  Here is a summary of the contents:
> FieldEnumerators : provides foreach syntax support when enumerating over all of the terms
in the index.
> TermVectorEnumerator : provides foreach syntax to allow for enumerating over all of the
term vectors in an index.
> BooleanFilter : combine multiple query filters in various logical combinations.
> TermsFilter : creates a filter from several terms as a logical OR.
> SegmentCache : a generic cache that works with the segment-level searching in Lucene
2.9 to cache any data at the segment level in the same manner as the field cache and  CachingWrapperFilter
which  I've used for caching aggregate data on the documents in a segment for use in diagnostics
and for caching TermVectors.  
> SegmentsGenCommit : adds the ability to open an index from the version specified in the
segments file as opposed to inferring the version from the files in the index directory.
> Refer to the documentation comments and unit tests for how to use the items.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message