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 <voze...@gridgain.com> 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. >
