You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by Shad Storhaug <sh...@shadstorhaug.com> on 2016/11/17 23:12:43 UTC

Build Tooling for Spatial4n

Hi Connie,

I have nearly reached the stage of porting Spatial4n where I need to make some decisions on setting up the multi-targeting aspect of it. I figured it would be a good opportunity to start working with .NET Core if I do the work on this small dependency of Lucene.Net.Spatial to migrate the code, set it up for multi-targeting and make the build script for it.

It occurred to me that there would be less friction in future porting efforts if Spatial4n, icu.net, and Lucene.Net all used the same tooling for the build (at least as much as practical). It would also be ideal if all of the build scripts were built from the same template. So I was wondering if you have made any decisions about which tooling to use, and if you might perhaps have (at least the start of) a build script and/or a sample of how you have/will setup the JSON file for the NuGet packaging that I can look at?


FYI - there are actually 2 dependent projects for Spatial4j, but Itamar has split up the port of this project into Spatial4n.Core and Spatial4n.Core.NTS. This means that Lucene.Net.Spatial only has 1 external dependency instead of 3. Previously, there were 2 NuGet packages that contained the same DLL (one with the NTS dependent classes compiled out), but going forward I think we should continue down this path by making two NuGet packages that are dependent (with no duplication of types), as follows:


              Lucene.Net.Tests.Spatial
                     /                     \
Lucene.Net.Spatial          Spatial4n.Core.NTS
                     \                     /            \
                     Spatial4n.Core          NetTopologySuite
                                                                    \
                                                                  GeoAPI


I am letting you know this primarily because GeoAPI currently has .NET Core support, but NetTopologySuite does not (although it is on their issues list).

There is only 1 test file that depends on NTS support, but the Lucene.Net.Spatial project does not depend on it. The test was setup in Java to be able to be skipped if the JTS (analogous to NTS) .jar wasn't installed, so I suggest we take a similar approach for .NET Core rather than porting the (very large) NetTopologySuite dependency just to support a couple of tests. For .NET 4.5.1, we can simply add this dependency to Lucene.Net.Tests.Spatial. In .NET Core we should probably aim for a way to skip the test if Spatial4n.Core.NTS isn't installed, and when .NET core support is eventually available for NetTopologySuite it can be added as a dependency on that stack as well.

Basically, the plan is to provide support for .NET Core for Spatial4n.Core, but not for Spatial4n.Core.NTS (at least not until it is available for NetTopologySuite).


Itamar,

Is there an existing MyGet feed for Spatial4n? If not, do you have a preference whether you or I set one up? If you want to handle it, please give me access to the feed so I can work with it (username nightowl888). If you are leaving it to me, I will just make you a feed owner - let me know.

The plan is to make a pre-release of Spatial4n on NuGet so it will be ready for when we get the pre-release of Lucene.Net on NuGet.


Thanks,
Shad Storhaug (NightOwl888)