I would love a separate repo. Someone told me that wasn't an option. If it's an option the let's make it so.
On Mon, Jan 16, 2017 at 11:20 AM Mark Bretl <mbr...@apache.org> wrote: > Jake, > > Having all the clients in the repository is nice, however, has there been > thought to have them in their own repository? Now that we are a TLP, we do > have that capability, as seen with the 'geode-examples' repository. > > --Mark > > On Mon, Jan 16, 2017 at 10:38 AM, Udo Kohlmeyer <ukohlme...@pivotal.io> > wrote: > > > -1 "geode-native" directory name > > > > +1 "geode-client" directory name > > > > Maybe the directories for the different clients are by language, so we > > omit the "geode" prefix i.e > > > > geode-client/ > > c++, > > net > > java > > python > > .... > > > > If clients are in their own project, then the clients can be > independently > > versioned of the server code. imo, there should be no need for them to be > > in lock-stead with the server code. > > > > --Udo > > > > > > > > On 1/16/17 08:52, Jacob Barrett wrote: > > > >> Let's try this again. Using the +1 mechanism for a multipart email is > >> tough > >> so please include a comment on which part you are +1ing. > >> > >> Also, I want to revise my suggestion to just call the directory > >> 'geode-native' rather than 'geode-nativeclient'. Simply because I am > lazy > >> and don't want to type the extra 6 letters all the time. > >> > >> -Jake > >> > >> On Mon, Jan 16, 2017 at 8:26 AM Jacob Barrett <jbarr...@pivotal.io> > >> wrote: > >> > >> One of the first things necessary to get NC merged into the the develop > >>> branch is understanding where it will go under the current geode > project > >>> structure. > >>> > >>> The quick and obvious solution is adding a 'geode-nativeclient` > >>> subproject > >>> and relocating all the NC sources into that directory. > >>> > >>> Given that NC consists of two semi-distinct clients, C++ and .NET, it > may > >>> also make sense to organize more of a hierarchy. Consider: > >>> geode-client/ > >>> geode++ > >>> geode.net > >>> (or some other more creative names) > >>> Keep in mind that today the .NET client is very tightly coupled with > the > >>> C++ client, so you can't build .NET without first building C++. > >>> > >>> My suggestion would be to do the quick and easy now and as we continue > to > >>> refine and refactor and hopefully write the .NET in pure CLI we make > that > >>> move them. Perhaps by that time there will be a pure Java client to > >>> include > >>> in that structure. > >>> > >>> Thoughts? > >>> > >>> > >>> -Jake > >>> > >>> > >>> > > >
