Alejandro,

I know I am delinquent in my response but there is better, more up-to-date information available now that I can link you to.

By all means C++ is well supported by DDS and there is no reason whatsoever that a participant in OpenICE cannot use C++ for development.  For the benefit of others I will point out that the first step is to generate C++ objects using our IDL definitions.
http://sourceforge.net/p/mdpnp/code/ci/master/tree/data-types/x73-idl/src/main/idl/ice/ice.idl
And optionally strings we use for nomenclature can be generated into constants in code with
http://sourceforge.net/p/mdpnp/code/ci/master/tree/data-types/x73-idl/src/main/idl/rosetta/

Next it's important to remember to use Quality of Service settings that are compatible with the demo-apps.  Our QoS profile are stored at
http://sourceforge.net/p/mdpnp/code/ci/master/tree/interop-lab/demo-apps/src/main/resources/META-INF/ice_library.xml
The easiest way to use this would be to copy this file to a file named USER_QOS_PROFILES.xml in the working directory of your program.  Once you've done that you can access the profiles by name with calls like create_XXX_with_profile.

Sounds like you figured out the semantics of the system on your own but for the benefit of others I maintain an architectural survey of the various topics that are published and the expectations of devices and apps at 
https://docs.google.com/a/jeffplourde.com/document/d/1g1zYd3kdxk8tL3zzkTJM38ied9Mi-prGTvvsf9LkDJw/edit

Getting back to your specific question you were spot on.  Publishing of HeartBeat and DeviceIdentity ought to cause your device to appear in the OpenICE demo-apps user interface.  I suspect that an incompatibility of QoS settings was causing your C++ based device not to be seen.

For a long while I had hoped to furnish a full example but have not had the time available; I apologize that it dramatically delayed my response to this really great question.  

Thanks
Jeff Plourde

Hi Vasanth,

You can create a gradle.properties in your home directory that specifies your HTTP proxy information.  More information is available at this link: https://gradle.org/docs/current/userguide/build_environment.html#sec:accessing_the_web_via_a_proxy

Please let us know if that information helps you to build successfully.

Cheers
Jeff Plourde

Hi Vasanth Jaisingh,

Thanks for your interest in the project.  Did you have access to the internet when you attempted the build?  There are numerous dependencies that gradle necessarily acquires as part of the build.  They get cached locally for subsequent builds but the first time you build they need to be retrieved from the internet.  Can you try the build with internet connectivity?  Specifically the build host in question must be able to connect at least to https://build.openice.info/artifactory.

Thank you
Jeff Plourde

Hi Dennis,
I’m sorry that the recent change broke the code for you and I greatly appreciate your reporting it and even including a patch. In our lab we’re still working on a really flexible deployment strategy for our ‘fleet’ of beaglebones. I added the /etc/issue as a quick way to see which had been upgraded to 14.04LTS. I should have done more research on the /etc/issue file in general before including it. I know a lot of folks at NIST who use CentOS, is that the distro you are using?

If I understand correctly what broke down was the lengthy string … probably throwing an exception in the CdrOutputStream? I’m really not thrilled about RTI’s API support for java programmers. On the plus side they have bound their underlying CDR (common data representation) libraries to java which is great. It means I can generate types natively in java (other implementations such as OpenDDS require types be generated in C++ first; then a JNI binding library is built specifically for those types … which is a multi-platform deployment nightmare). But on the other hand they do not support the standard java DDS API (I believe they plan to in the future) So as you can see the one adjustment I made to your patch was to jump some hurdles to avoid hardcoding the length (128). It would be nicer in java if they annotated max lengths in a way that facilitated validation. The commit in SourceForge git viewer:
http://sourceforge.net/p/mdpnp/code/ci/5757b04fabe6c870e748e7922a8573cc45a152b3/

If you wouldn’t mind I’d love to hear more about how you are using the code. Should I expedite a new release for you or are you building from source? If I know your particular areas of interest I can try to involve you in relevant discussions about how OpenICE should evolve. Also if you have issues or comments we’ve set up a website at http://community.openice.info that you can use in the future.

Thanks again,
Jeff

Hi Rado,

Glad I could help.  Let us know if you have any other questions.

Thank you
Jeff

Hi Rado,

Thanks for the feedback regarding java 8.  I realize the end of life for java 7 is looming and we'll make the switch eventually but for now the gradle build is set up to explicitly use Java 7.  In fact if you generate eclipse projects using the eclipse plugin for gradle they should have the appropriate language and byte code compliance settings in place.

That said I wonder if you have more information about the build errors you received under java 8?  Implementing multiple interfaces doesn't sound like it should be a compile error.  Also I just tried changing compliance settings to Java in the root build.gradle and didn't experience any errors so I'm especially curious.

The build has been streamlined as much as possible for purposes of continuous integration but I agree getting the projects loaded into IDEs could be streamlined further.  If you have any suggestions we'd be happy to make changes.  As of right now we've had the most success with the eclipse plugin for gradle "./gradlew eclipse" and then importing projects into Eclipse from there.

Thanks!
Jeff

Hi Rado,

Thank you very much for contacting us. I'm sorry that you've run into problems with the software. I hope the following information is useful but please don't hesitate to ask further questions.

If you'd like to develop your own software to interact with the OpenICE system you can utilize our prebuilt libraries. An example of how to do this is available at https://github.com/mdpnp/hello-openice. Those libraries are hosted on our artifactory instance at build.openice.info.

If you would like to build all the software yourself from our SourceForge that is also possible. The generation of java code from IDL definitions has been automated in the build process but it sounds as if that target is not being executed in your environment. Most of the code generated from IDL into java will be placed into an "ice" package. The easiest way to ensure all the appropriate code gets generated is to execute from the command line (from the root of the git repo):
./gradlew :interop-lab:demo-apps

If you would like to get more granular the key sub-project for generating java code from IDL is :data-types:x73-idl-rti-dds. (This project is a dependency of the demo-apps project I previously mentioned). From the command line you can trigger code generation directly with
./gradlew :data-types:x73-idl-rti-dds:build

If you’d prefer to stay within the eclipse environment you can highlight the x73-idl-rti-dds project from the Package Explorer, from the ‘External Tools’ menu select “Run As” “Gradle Build…”, and enter “build” for the task name.

Thank you and let us know if you have any more questions,
Jeff Plourde

Hi Alejandro

A root cause for the SIGILL on shared object initialization proved elusive since the instruction in question (CBZ) *should* be legal in the ARMv6 Thumb-2 extensions.  The text segment may have been corrupted or poorly aligned for an unknown reason.  Nevertheless I was able to relink the shared objects in question with ordinary ARMv6 instructions only (-march=armv6) and we have tested the result successfully on Raspberry Pi.  I'll communicate my fix to RTI as well.

Please try version 0.4.3 of our software on SourceForge (which incorporates the fix) and let us know the results.  Thanks again for the feedback!

Jeff Plourde