paulirwin commented on issue #1022:
URL: https://github.com/apache/lucenenet/issues/1022#issuecomment-2673451312

   An update on this, since it's a big item and taking a while. So far, the 
following are implemented:
   
   - A Java tool to load Lucene packages from Maven and extracting their public 
API to a JSON file
   - A .NET CLI tool (and Powershell script to facilitate it) to load the 
aforementioned JSON file, reflect over the specified Lucene.NET libraries, 
compare differences, and generate a diff report
   - The generation of both a JSON diff file (for programmatic use, if desired) 
as well as an HTML report generated using Handlebars (this is my preferred way 
to use this)
   - Analysis of types in Lucene missing from Lucene.NET
   - Analysis of types in Lucene.NET missing from Lucene
   - Analysis of differences in modifiers of types between Lucene and 
Lucene.NET, accounting for Java vs .NET differences (i.e. `final` vs `sealed`, 
different meanings of `static` classes)
   - Analysis of differences in base types
   - A new Lucene.Net.Reflection namespace containing attributes and extension 
methods to make it easier to reflect over Lucene.NET types. This includes:
     - A `NoLuceneEquivalent` attribute to suppress things in Lucene.NET that 
aren't in Lucene
     - A `LuceneType` attribute to map a Lucene.NET type to a Lucene package 
and type when the mapping can't be inferred by convention
     - A `LuceneMavenMapping` assembly-level attribute to specify Maven 
coordinates for the corresponding Lucene artifact
     - A `LucenePackageMapping` assembly-level attribute to manually override 
namespace-to-package mappings that can't be inferred by convention (i.e. 
`org.apache.lucene` can be mapped to `Lucene.Net` by default, but pluralization 
differences require this attribute)
     - Extension methods on Assembly to get the package mappings
     - A `GetLuceneTypeInfo` extension method on Type to get the corresponding 
Lucene type info (either inferred or manually overridden via those attributes)
   
   The following work remains:
   
   - [ ] Attribute to suppress modifier differences
   - [ ] Attribute to suppress base type differences
   - [ ] Analysis of differences in interfaces
   - [ ] Analysis of differences in fields and enum members
   - [ ] Analysis of differences in constructors
   - [ ] Analysis of differences in non-property methods
   - [ ] Analysis of differences in .NET properties to Java getter/setter 
methods
   - [ ] CI build support for running this utility
   - [ ] Determine feasibility of analyzing the Analysis.OpenNLP library 
(targets a different Lucene version)
   
   While this new utility certainly could go further than that longer-term 
(i.e. analyzing attributes/annotations, unit tests, etc.) I think this should 
be sufficient for our needs to get a feeling for how close our 4.8.0 release 
will be to Lucene. Future work could be split out as separate issues.
   
   And while I'm adding some manual mappings via attributes as part of testing 
this work, I do not intend to address every API difference in this PR. Instead, 
it will help inform what work remains in either finishing adding remaining 
mappings, or, if there are things missing in Lucene.NET, what needs to be done 
in separate issues to close the gap.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@lucenenet.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to