This page last changed on Nov 03, 2013 by zigenz.

Hi guys,

Firstly, I'd like to say that the whole Open Remote project is mighty impressive and well done to all contributors for getting it to where it is!

I myself have a lot of automation capability in my home but I haven't yet tied it all together! I was planning on writing my own application/s but it seems that the Open Remote community has done all the hard work. From what I can see, all that I would need to add would be some specific adaptation layers for the various systems.

My background is embedded 68K (C / C++ / assembly), MFC, .NET, and more recently Windows Metro apps (C++ / C#). Historically, I've been quite anti-Java, but through age comes wisdom and I can safely say that I'm over my prejudices now. Whilst the Java language/syntax is simple enough, I openly admit that I know nothing about the quirks of the environment, resolving dependencies, adding packages etc.

The systems that I would be looking to adapt would be CBus, DALI, and Daikin DIII-Net (via the Modbus interface over Ethernet). I have a bunch of Raspberry Pi units and would be looking to develop in Windows (preferably, although I can set up a Linux VM if necessary) and remote debug on the Pi.

For someone like me, the pain (i.e. time wasting) will be in getting the environment set up, getting remote debug working and understanding how to navigate around the IDE (I assume Eclipse if the preferred weapon of choice for most?). So my question is, is there a "Setting up a Controller Build 101" guide available? If not, would someone pen down some high(-ish) level instructions to get me started?

On a side note, basically all the systems I will be talking to will be using "virtual" serial ports over a telnet connection. I already have written a rock solid multi-threaded state-machine based adaptor in C++ . It's an MS specific implementation, but wouldn't take much to port to POSIX. Now, the thing is, I prefer to keep something like this (which benefits greatly from multithreading) in C / C++. In light of this, is it possible in Java to natively access the exports from these libraries and furthermore, is that an acceptable development paradigm for this project?

Thanks for your help in advance.


Hi Zyrus,

1) Install ant build tool from somewhere in your path

2) checkout a stable tag from subversion, e.g.

> svn co

(assume svn is already installed somewhere in your path)

3) go to the root of the directory you just checked out, there's a file build.xml there. Now type:

> ant

The build will start, you will find the compiled binaries in the /output directory.

Learning an IDE is optional. The project will always be buildable without one. And we don't mandate you use any specific one. Using any programmers editor is fine for small changes (and may even be recommended given that IDEs introduce an unnecessary learning curve). I find the value of an IDE in the just-in-time parsing (so it points my errors before I hit the build cycle), in the just-in-time lint when I write code that stinks, and in the automated refactoring capabilities (relevant when making changes that affect large parts of the code). Learn an IDE if you find them valuable. I prefer IntelliJ myself, but I only use it for the capabilities described above (as a really smart editor mostly). So basically I've evolved only slightly above the 68k toolchains (which were fun times). Most of the stuff Java developers rave about is unnecessary and over-complicated fluff they use to hide their insecurities and doesn't make them any better programmers.


– Juha

Posted by juha at Nov 04, 2013 09:33

I'm going to chime in as an avid IDE buff. If you pick up an IDE for java, you might want to use Eclipse. It has a drools plugin which will give you some code completion and on the fly syntax checking when you edit drool files. It's also a pretty standard tool among Java devs. I agree with Juha in that the biggest benefits are the jit and automatic refactoring. In my opinion, the ability to drop into a debugger which shows you the call stack along with the locals at each level of the stack is the other big reason you would want to use an IDE like eclipse. It lets you get familiar with unfamiliar code really quickly. It also speeds up debugging quite a bit, especially if the program is passing around a lot of strings or something rather than going super custom class heavy.

I've made changes to a branch which make the eclipse project definition stable. I don't know if those are part of the trunk yet. I've also written instructions on setting up the controller with eclipse here:

Posted by melchoir55 at Nov 05, 2013 01:51

Thanks guys for the recommendations. Will test out both this weekend and see which method works for me.


Posted by zigenz at Nov 05, 2013 04:16

I'm in the same position as Zyrus, and also have some problems setting up the environment.
I followed Isaac's documentation and can execute runt-test, compile and package(build.xmll targets) from within Eclipse.

What I also want to do(inside Eclipse IDE), but failed to achive yet
quickly start the controller (run does not work), missing Jetty and paths seems to be wrong.
quickly start the controller in debug mode, setting breakpoints before or after the start, and then debug from within Eclipse.

Im using VS and .Net every day, but never used Eclipse before, so please just point me in the right direction

/Rgds, Hans

Posted by hansn at Nov 16, 2013 20:30

Sorry for not seeing this sooner, Hans. Are you saying that you cannot launch the controller from Eclipse?

Posted by melchoir55 at Nov 24, 2013 03:37

I wrote a guide for attaching to the running controller process using eclipse. After attaching, any breakpoints the program hits will break and send you into the debug perspective.

Posted by melchoir55 at Nov 28, 2013 01:45

Thanks for your answer.

It now works to start tomcat in debug, with the project and attach the debugger.
I thought that it could be done as in VS, starting debug from inside Eclipse would compile/build/start server/attach debugger automaticly

When I followed your Setup instructions, in paragraph D, it didn't work to run
It works to run run-test in Ant dough...

One more thing, is it possible (by Ant) to just compile the classes modified, to speed things up?

Posted by hansn at Dec 04, 2013 23:23

I thought that it could be done as in VS, starting debug from inside Eclipse would compile/build/start server/attach debugger automaticly

This is possible, but much harder.

I'm concerned that you could not run through eclipse, but I cannot really offer any troubleshooting without knowing what you're running up against.

One more thing, is it possible (by Ant) to just compile the classes modified, to speed things up?

I doubt it, but I'm no expert so don't take my word for it. My ant build goes pretty quick. Are you developing on a slow machine? If not there might be something weird going on.

Posted by melchoir55 at Dec 05, 2013 00:53

One more thing, is it possible (by Ant) to just compile the classes modified, to speed things up?

You can, with slight modifications in the build.xml file. The original Ant build has been written somewhat strangely, by having the "init" task depend on "clean" so it always deletes all the project structure so a full compile is done every time. This makes sense from the release point of view (you always want to build a release from zero status) but not so much for incremental development.

The normal <javac> task of Ant is incremental compile, so normally nothing extra needs to be done. You can just define your own target that does an incremental build, following the example used with a single unit test execution target which has this internal compile target:

   | Incremental compile of the project classes
  <target  name = "-compile-incremental">

    <echo message = "--------------------------------------------------------------------"/>
    <echo message = " Compiling project classes (incremental) ..."/>
    <echo message = "--------------------------------------------------------------------"/>
    <echo message = ""/>

    <copy todir = "${classes.dir}">
      <fileset dir = "${config.dir}">
        <include name = "**.*"/>

    <copy todir = "${webapp.classes.dir}">
      <fileset dir = "${classes.dir}">
        <include name = "**.*" />

    <javac destdir = "${classes.dir}" classpathref = ""
           debug = "${build.debug}" encoding = "${default.javac.encoding}">
      <src path = "${src.dir}"/>


Caveat here is that you may need to check that a proper "init" task (or an equivalent) has been done before the first run to build the dependent directory hierarchies. You may need to do some additional tweaking for resource file handling (if they're updated). And sometimes javac itself trips up on incremental builds (not detecting constant value changes although that might be a historic thing and addressed since I last time saw that happen).

Anyway, incremental compile is default for the javac compiler so it's pretty trivial. The build just needs to be cleaned up to include development builds as well as release builds.

Posted by juha at Dec 05, 2013 01:16

Or in other words, "release" should be a separate target that depends on clean, and the default should be an incremental compile.

Posted by juha at Dec 05, 2013 01:21
Document generated by Confluence on Jun 05, 2016 09:30