ohNet and ohNetGenerated - what is the reason for the split ?

[freshman]

Hello,

As I'm beginner on this forum as well as in OpenHome API (as my nick says that Smile ), then, please, forgive me the question, which can be obvious for more advanced OH developers.
And the question is as in the title of the thread: why these two branches are, in fact, two separate ones, instead of being a single one?
Additionally to that, ohNetGenerated uses ohNet, and, at the moment of writing this thread, it uses its relatively old version (fetched by go fetch --all command).

I am asking for that, as in my humble opinion, this split was rather risky step - it may drive to some, even serious inconsistencies, which may result in impossibility to build newer versions of ohNetGenerated libraries (including Java, etc) ...

Fortunately, at this moment, ohNetGenerated is built successfully against the newest ohNet libraries, but - are we sure, that this situation will NOT change in a future ... ?

thanks and regards
Freshman

[simonc]

Before answering this directly, it's worth recapping the purpose of each of the repositories:

ohNet provides a base UPnP stack, language bindings and the tools needed to generate proxies and providers in all supported languages. These components are always updated and tested together.

ohNetGenerated uses the tools published by ohNet to generate proxies and providers for some commonly used services. These only require update when the templates used to generate code or a tiny number of ohNet APIs change. These area change very rarely.

We split the code into two separate repos (note: not branches) to allow for faster, easier development of ohNet itself. We run builds & tests for 15 different platforms after every commit. More than half the time for this was being spent compiling generated code which almost never changes. As well as delaying ohNet development, this was placing a high load on our CI servers which was impacting many other projects.

Splitting the repos also gives us more scope to include more services from more manufacturers into ohNetGenerated in future.

You shouldn't worry if you have a project that depends on both repos. You can always use a version of ohNet that matches your chosen ohNetGenerated. In the unlikely event that ohNet has bug fixes or new features that are desirable to you but make its latest code incompatible with the tip of ohNetGenerated, you can easily use the tools/templates released by ohNet to regenerated your own proxies or providers.

[freshman]

(23-03-2015 01:19 PM)simonc Wrote:  Before answering this directly, it's worth recapping the purpose of each of the repositories:

ohNet provides a base UPnP stack, language bindings and the tools needed to generate proxies and providers in all supported languages. These components are always updated and tested together.

ohNetGenerated uses the tools published by ohNet to generate proxies and providers for some commonly used services. These only require update when the templates used to generate code or a tiny number of ohNet APIs change. These area change very rarely.

We split the code into two separate repos (note: not branches) to allow for faster, easier development of ohNet itself. We run builds & tests for 15 different platforms after every commit. More than half the time for this was being spent compiling generated code which almost never changes. As well as delaying ohNet development, this was placing a high load on our CI servers which was impacting many other projects.

Splitting the repos also gives us more scope to include more services from more manufacturers into ohNetGenerated in future.

You shouldn't worry if you have a project that depends on both repos. You can always use a version of ohNet that matches your chosen ohNetGenerated. In the unlikely event that ohNet has bug fixes or new features that are desirable to you but make its latest code incompatible with the tip of ohNetGenerated, you can easily use the tools/templates released by ohNet to regenerated your own proxies or providers.

Thanks Simon for your quick answer
Although it still seems to me, that faster compilation can be ensured by well written makefiles , my life learnt me humility, especially in case, when I am a beginner in a new environment - and in such cases I assume, that I am probably not right - it is often a good assumtion, as when my knowledge grows I usually conclude that nothing happens without a reason. And in this case I assume, that after some time I'll discover real benefits of this split . As I have written - at this moment I have no problems with building ohNetGenerated against the newest ohNet, and everything seems to be OK. Hmm - with one exception : makefiles used to build ohNet and ohNetGenerated allows for building java code only, when 32-bit JDK is installed. They have hardcoded a path to 32-bit java:
ibjvm_dir ?= $(JAVA_HOME)/jre/lib/i386/server
Of course, in case, when only 64bit JDK is installed, the java compilation fails. It was no problem to me to fix it, by changing i386 to amd64, however, maybe it would be a good idea to parametrize it ... ?

Once again - thanks for the quick answer
Freshman