On Fri, Oct 20, 2017 at 6:02 PM Dan Smith <dsm...@pivotal.io> wrote: > However I do think we should be compiling (and hopefully running!) > these examples so that they don't rot over time. Especially since I > believe we are still evolving the native API with breaking changes and > have not actually managed a release for the native code yet? >
If someone in the community has the bandwidth to setup a windows jenkins build the system requirements and instructions are in the geode-native README.md. There is a very specific set of toolkit needed to build Geode Native. After getting Native building you will need to find a way to update the csproj files with the path to the Apache.Geode.dll before building the examples solution. I would recommend CMake for that process but a simple sed replacement works too. One option if it is too hard to automate the build of these things in > geode-examples is that we could put them into geode-native until we > actually release geode-native. I think it is just fine keeping them where they are. I have very strong reservations about treating the geode-examples repo as some blessed and released repository. If it is that strongly coupled with the Geode release then it should have never been moved to its own repo. Geode Native was put in its own repo to allow Geode Native to develop and release on an independent cycle than that of the Geode server and java client. The same rational was used to support the creation of geode-examples repo. This should be a living and breathing ground for community based examples. If ware going to treat it as product and product that is tied to the geode repo then those components should be moved to the geode repo. If the community disagrees then I will gladly move the native examples out of geode-examples. -Jake
