I agree with Jake - I don't think having a single build process really
serves either side well. In all my time using GemFire/Geode I've never once
had a need to build (or even use) the Native Client component. Given that
the majority of users/developers will be only Java focused, I don't think
Thanks Jacob.
Build goes fine with this change.
Thanks
Avinash
On Tue, Jan 17, 2017 at 5:17 AM, Jacob Barrett wrote:
> Avinash,
>
> We just added some changes to the Geode dependency. You should be able to
> set cmake -DGEODE_ROOT=/path/to/apache-geode. Without that flag
Avinash,
We just added some changes to the Geode dependency. You should be able to
set cmake -DGEODE_ROOT=/path/to/apache-geode. Without that flag set it will
look for Geode in:
/geode/bin
/apache-geode/bin
/usr/geode/bin
/usr/apache-geode/bin
/usr/local/geode/bin
> On Jan 16, 2017, at 11:49 AM, Jacob Barrett wrote:
>
> So you envision a world where someone who doesn't care about native clients
> must build the native clients as part of the root gradle build and a person
> not interested in building the Java bits must you gradle to
Avinash,
There are several things we need to do to get this new dump working with
geode before we came merge it into the main branch. You should start seeing
a series of tickets being opened Monday to address this and many other
issues.
Thanks,
Jake
On Sun, Jan 15, 2017 at 2:24 AM Avinash
This is great.
Need to make following change to PASS the build.
diff --git a/src/tests/javaobject/CMakeLists.txt
b/src/tests/javaobject/CMakeLists.txt
index 4924e5c..7f85878 100644
--- a/src/tests/javaobject/CMakeLists.txt
+++ b/src/tests/javaobject/CMakeLists.txt
@@ -9,8 +9,8 @@
I am pleased to announce the donation of improved GemFire client
drivers to the Geode community. This source code donation includes a
C++ client and a .NET client. This new grant attempts to greatly
improve the mergability of the code base making it friendlier to the
community by providing an