Interfaces for .NET platform

[desruisseaux]

This is an umbrella issue for tasks related to integration of some .NET interfaces. This work could be done in collaboration with an independent project, .NET GeoAPI, which provides interfaces inspired from OGC GeoAPI. The interfaces compliant to OGC/ISO standards could be ported to this OGC GeoAPI project, as discussed around May 29th 2018 on https://github.com/NetTopologySuite/GeoAPI/issues/30. Initial list of tasks that may be done:

• Revisit the build system: is Maven still appropriate for a language providing Java/Python/C++/.NET variants? Would Gradle be more adapted?
• Eventually use the Java interfaces as template for .NET interfaces, with omission of Java-specific aspects and adaptation to .NET conventions. Alternatively we could also start from NetTopologySuite/GeoAPI interfaces and verify their conformance to OGC/ISO models. Or a mix of both approaches.
• Defines binding between .NET interfaces and Java interfaces and verify (as an inter-operability demonstration) that a .NET implementation can execute the test suite written in Java.

[kinow]

Revisit the build system: is Maven still appropriate for a language providing Java/Python/C++/.NET variants? Would Gradle be more adapted?

If we had something like 10 different variants, the gradle build could get a bit too complex I think. Perhaps have independent builds per language would work best?

[desruisseaux]

I'm fine with independent builds per language. But do we keep some relationship between them (directory structure, etc.)? I wonder how to express the fact that the interfaces in different languages are derived from the same model?

Another issue is the binding between different languages (e.g. Java - Python bindings). They may require a common build system?

[kinow]

Would it make sense to move each one to its own project? This way I think Java users could easily navigate the commit tree/tags of the Java project, and idem for Python/.NET/etc.

This way they could have independent build systems as well.

A compromise, would be to follow what Spark did. They have R and Python projects within the same directory.

But I don't believe they have anything to do with the pom.xml in the root dir. The python folder contains the setuptools files, and R has some shell scripts.

[desruisseaux]

Moving each language to their own project make me worry that they would diverge. The intent is that interfaces would be derived from the same OGC/ISO model, and if a change is applied in one language (for other reason than a language-specific issue), it should be applied consistently in all languages. The binding between languages may also need synchronization.

Another aspect is that the different languages would have many common modules. For example all languages may have "geoapi", "geoapi-conformance" and "examples" modules with similar content. Given that Maven and Gradle already uses src/main/java directory, it seems a natural extension to have src/main/python and src/main/net directories:

master
 ├─ geoapi
 │   └─ src
 │       ├─ main
 │       │   ├─ java
 │       │   ├─ net
 │       │   └─ python
 │       └─ test
 │           ├─ java
 │           ├─ net
 │           └─ python
 ├─ geoapi-conformance
 │   └─ src
 │       └─ main
 │           ├─ java
 │           ├─ net
 │           └─ python
 └─ geoapi-examples
     └─ src
         └─ main
             ├─ java
             ├─ net
             └─ python

(Directory structure is also discussed in https://github.com/opengeospatial/geoapi/issues/30) I don't claim that this is the best way to do; it is just a way to keep related objects closer, where their similarities in the conceptual model they implement is considered more important than the language. It may also help to declare common configurations only once (license, repositories, test files, …).

According https://github.com/gradle/gradle/issues/1428 it seems that C++ support with Gradle would be good and C# support may be closer than with Maven. I'm not requesting for a decision to be taken soon; only exploring possibilities. Thanks for your inputs!