lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From NightOwl888 <>
Subject [GitHub] lucenenet issue #203: API Work - Stabilization
Date Mon, 27 Feb 2017 01:02:19 GMT
Github user NightOwl888 commented on the issue:
    I also apologize for the delayed response.
    > Is there anything I can help with?
    Yes, there is. I have been working on cleaning the API up and making it more .NET-like.
    ### CLS Compliance
    Part of this process is making the whole project CLS compliant, so it can be consumed
by VB and other .NET languages.
    1. Currently, there are only 8 remaining CLS-related warnings that need to be addressed.
But before we fix them, it would be nice if we could ensure that the fixes don't cause any
negative effects - in other words, we need as many tests fixed as possible (namely in Lucene.Net.Core).
If you could help with the debugging efforts, that would be great.
    2. In addition, there was a bit of a snag with icu-dotnet because *it* is not marked CLS
Compliant. Therefore, by default none of its types are CLS Compliant and cannot be exposed
publicly in Lucene.Net (including Enum types). I would appreciate it if you mark the assembly
with the CLSCompliant attribute.  
    I reverted the ThaiAnalyzer back to its previous state and adapted the ICUBreakIterator
to work with it - seems to work pretty well, for now (and it is now CLS Compliant). Let me
know if/when you have a rule-based break iterator so I can ensure compatibility.
    ### Collation
    Also, I ended up marking the Collation-related types CLSCompliant(false). I am now pretty
much convinced that there is no way we can get them working with icu-dotnet, based on [this
It also seems to indicate that the collation functionality in the Analysis.ICU package is
better (and it is based on ICU 4J, so it should work). Anyway, my thought is to add `FEATURE_COLLATION`
as an option and leave it out of the compile, since it is pretty much useless unless we port
over a large part of the JDK to make it work. So, ignore those failing tests for the time
    ### Test Framework
    I also reverted the changes to OLD_FORMAT_IMPERSONATION_IS_ACTIVE and made it static again.
There really doesn't seem to be a reasonable way to ensure this flag is read from everywhere
if it is non-static. This fixed more than a dozen failing tests. I am working on finishing
up the Codec functionality now - specifically the randomizing of codecs and the IgnoreCodecs
    But, I could use some help. The test framework has been a major source of test failures.
Many parts of it were not translated correctly or are still unfinished. IMO, the test framework
should be reviewed line-by-line to ensure that the equivalent functionality is implemented.
    ### Documentation Comments
    Also, as I [mentioned above](,
some of the documentation comments need to be finished. Mostly, they are malformed so they
don't show up in Visual Studio, but there is also some documentation that is either incorrect
or has not been brought over from Lucene.

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

View raw message