Re: Native client examples

[Dan Smith]

For geode-examples I think it makes sense that they are on released with
geode (which they are, see
https://cwiki.apache.org/confluence/display/GEODE/Release+Steps). We are
currently adding examples for features that will be available in geode 1.4,
so we want those to be released in sync with geode 1.4.The geode-examples
are not in separate repo to have a separate release cycle. They are in a
separate repo to make it easy for someone to just clone the example source
and start using it.

Back to the original question - we've been trying to make sure the java
examples in geode-examples get compiled and run as part of the travis build
for the geode-examples repo. Any PR for the geode-examples repo goes
through that travis build. I think the C# examples also need compile and
run otherwise they will rot and be hard to maintain. If it's too hard to
get them to compile as part of geode-examples, moving them into
geode-native and building them as part of that build process seems like a
good start.

-Dan

On Mon, Oct 23, 2017 at 11:09 AM, Anilkumar Gingade 
wrote:

> In line with geode-core and geode-examples any thoughts about having
> geode-native-examples (on its own repo)...
>
> -Anil.
>
>
> On Mon, Oct 23, 2017 at 9:18 AM, Jacob Barrett 
> wrote:
>
> > On Fri, Oct 20, 2017 at 6:02 PM Dan Smith  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
> >
>

Re: Native client examples

[Anilkumar Gingade]

In line with geode-core and geode-examples any thoughts about having
geode-native-examples (on its own repo)...

-Anil.


On Mon, Oct 23, 2017 at 9:18 AM, Jacob Barrett  wrote:

> On Fri, Oct 20, 2017 at 6:02 PM Dan Smith  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
>

Re: Native client examples

[Anthony Baker]

The thread I referenced discussed the topic of different release cycles for our 
repos.  The ASF viewpoint is that if you have separate release cycles for 
different repos you have an independent subproject.  And a subproject implies a 
different community and PMC.

Anthony


> On Oct 23, 2017, at 10:17 AM, Jacob Barrett  wrote:
> 
> Anthony, I don't see the relevance of the thread you mention. Can you
> please explain how a discussion on tagging releases in JIRA relates to this
> discussion?
> 
> On Mon, Oct 23, 2017 at 10:06 AM Anthony Baker  wrote:
> 
>> Before we start this thread again, please read [1].
>> 
>> Anthony
>> 
>> [1]
>> http://mail-archives.apache.org/mod_mbox/geode-dev/201701.mbox/%3cdb3f0e86-1d8f-4acc-8323-fe8c135b3...@pivotal.io%3e
>> <
>> http://mail-archives.apache.org/mod_mbox/geode-dev/201701.mbox/%3cdb3f0e86-1d8f-4acc-8323-fe8c135b3...@pivotal.io%3E
>>> 
>> 
>> 
>>> On Oct 23, 2017, at 9:51 AM, Addison Huddy  wrote:
>>> 
>>> I agree with Jake that the examples directory should not be part of our
>>> official releases.  They should be a light-weight entry point to our
>>> community, meaning they should be easy to create, modify, and use.  While
>>> counter-intuitive, in this case, a less official approach to our examples
>>> will yield fresher and more helpful examples.
>>> 
>>> On Mon, Oct 23, 2017 at 9:18 AM, Jacob Barrett 
>> wrote:
>>> 
 On Fri, Oct 20, 2017 at 6:02 PM Dan Smith  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
 
>> 
>> 

Re: Native client examples

[Jacob Barrett]

Anthony, I don't see the relevance of the thread you mention. Can you
please explain how a discussion on tagging releases in JIRA relates to this
discussion?

On Mon, Oct 23, 2017 at 10:06 AM Anthony Baker  wrote:

> Before we start this thread again, please read [1].
>
> Anthony
>
> [1]
> http://mail-archives.apache.org/mod_mbox/geode-dev/201701.mbox/%3cdb3f0e86-1d8f-4acc-8323-fe8c135b3...@pivotal.io%3e
> <
> http://mail-archives.apache.org/mod_mbox/geode-dev/201701.mbox/%3cdb3f0e86-1d8f-4acc-8323-fe8c135b3...@pivotal.io%3E
> >
>
>
> > On Oct 23, 2017, at 9:51 AM, Addison Huddy  wrote:
> >
> > I agree with Jake that the examples directory should not be part of our
> > official releases.  They should be a light-weight entry point to our
> > community, meaning they should be easy to create, modify, and use.  While
> > counter-intuitive, in this case, a less official approach to our examples
> > will yield fresher and more helpful examples.
> >
> > On Mon, Oct 23, 2017 at 9:18 AM, Jacob Barrett 
> wrote:
> >
> >> On Fri, Oct 20, 2017 at 6:02 PM Dan Smith  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
> >>
>
>

Re: Native client examples

[Anthony Baker]

Before we start this thread again, please read [1].

Anthony

[1] 
http://mail-archives.apache.org/mod_mbox/geode-dev/201701.mbox/%3cdb3f0e86-1d8f-4acc-8323-fe8c135b3...@pivotal.io%3e
 



> On Oct 23, 2017, at 9:51 AM, Addison Huddy  wrote:
> 
> I agree with Jake that the examples directory should not be part of our
> official releases.  They should be a light-weight entry point to our
> community, meaning they should be easy to create, modify, and use.  While
> counter-intuitive, in this case, a less official approach to our examples
> will yield fresher and more helpful examples.
> 
> On Mon, Oct 23, 2017 at 9:18 AM, Jacob Barrett  wrote:
> 
>> On Fri, Oct 20, 2017 at 6:02 PM Dan Smith  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
>> 

Re: Native client examples

[Addison Huddy]

I agree with Jake that the examples directory should not be part of our
official releases.  They should be a light-weight entry point to our
community, meaning they should be easy to create, modify, and use.  While
counter-intuitive, in this case, a less official approach to our examples
will yield fresher and more helpful examples.

On Mon, Oct 23, 2017 at 9:18 AM, Jacob Barrett  wrote:

> On Fri, Oct 20, 2017 at 6:02 PM Dan Smith  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
>

Re: Native client examples

[Jacob Barrett]

On Fri, Oct 20, 2017 at 6:02 PM Dan Smith  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