Dmitriy, Raul, In current GridGain codebase we keep everything in a single repository and a single module. Here is why: 1) We have 4 distinct parts: Java supporting code, common CPP/JNI layer which depends on Java, .Net implementation which depends on Java and JNI, CPP platform implementation which depends on Java and JNI. And very often it is necessary to update several of them in scope of a single ticket. It will be a nightmare to update them in different repos - tons of patches and/or pull requests. 2) We have them in a single module because we are Maven-based project. From .Net/CPP user perspective it doesn't matter whether C++ code they are going to build is located inside $IGNITE_HOME/modules/platform/src/main/cpp or $IGNITE_HOME/modules/platform_cpp/src. I do not see what are advantages of shuffling non-Java files a bit differently across the repo. "src/main/*java*" folder in Maven was "invented" for such cases as well.
Vladimir. On Fri, Aug 21, 2015 at 6:33 PM, Raul Kripalani <[email protected]> wrote: > Have you considered the possibility of hosting these codebases in separate > Git repos? > > I don't think it's a good idea to mix so many technologies within a single > source tree. > > You can have a look at how ActiveMQ do it with their C++ [1] and .NET [2] > clients – one repo for each technology to keep the build and project > lifecycles sane. > > [1] http://activemq.apache.org/cms/source.html > [2] http://activemq.apache.org/nms/source.html > > Regards, > > *Raúl Kripalani* > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source > Integration specialist > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani > http://blog.raulkr.net | twitter: @raulvk > > On Fri, Aug 21, 2015 at 2:50 PM, Vladimir Ozerov <[email protected]> > wrote: > > > Igniters, > > > > I am starting migration of C++/.Net integration modules donated by > GridGain > > to Ignite. I am going to put all that stuff, including Java classes, .Net > > classes and .cpp/.h files in a new module. > > > > In GridGain we first named this stuff "clients" and later "interop". But > > there are several problems with these namings: > > 1) These are not clients, but rather fully-fledged Ignite nodes operated > > through non Java-platform. > > 2) "interop" is a jargon and do not give user clear understanding on what > > API is about. > > > > Batter name for that module which comes to my mind is "platform". And > > following our standard naming conventions for Java classes there will be > > something like "PlatformDotNetConfiguration", "PlatformProcessor", etc.. > > > > Any more ideas on how to name this stuff? > > > > Vladimir. > > >
