Slides are the mind-killer.
Slides are the little-death that brings total obliteration.
I will face my slides.
I will permit them to pass over me and through me.
And when they are gone past I will turn the inner eye to see their path.
Where slides have gone, there will be nothing.
Only code will remain.

One of the fundamental development activities that you need to be able to perform for any software you are working with is to run it in a debugger. OpenDaylight controller is no different.

The OpenDaylight controller is an OSGI application, which means its an assembly of many OSGI bundles running in an OSGI container, so it’s not quite as simple as debugging a simple Java app with a main() method, but it’s not really all that much harder 🙂

First, you will need to set up your target. In Eclipse, open:

controller/opendaylight/distribution/opendaylight/opendaylight.target

And click on ‘Set as Target Platform’:

Setting up the ‘target’ for OpenDaylight Controller in Eclipse.

Second, let’s set a breakpoint so we can see the debugger in action. In this example, I’m setting a break point in the arphandler project in
org.opendaylight.controller.arphandler.internal.Activator at line 78. Since the Activator for a bundle is always called during startup of that bundle, this breakpoint will get tripped during the startup of the controller. You set a break point in Eclipse by double clicking next to the line where you want the breakpoint:

Set a breakpoint in arphandler project at org.opendaylight.controller.arphandler.internal.Activator line 78.

Third, we need to run the Debugger configuration for opendaylight. To do this, in the menu for Eclipse select ‘Run’->’Debug Configuration…’ which will bring up the ‘Debug Configuration’ dialog. Select ‘OSGI Framework’->’opendaylight-osgi-launcher’ and click ‘Debug’:

Launching the ‘opendaylight-osgi-launcher’ for debugging.

This will run the controller. You will be able to see the progress in the ‘Console’ view:

OSGI console. Yes, you can type OSGI console commands here.

When the ArpHandler bundle is loaded, and it’s Activator run, you will see the debugger stop at the breakpoint we set:

Debugger stopping on breakpoint in Arphandlers Activator.

There are other very good introductions to the power of the Eclipse Debugger here and many more here.

OpenDaylight uses for code review prior to merge. So what if you want to contribute a change based on a Gerrit that has not yet been accepted and merged into Gerrit?

(NOTE: Do not use this method to merely make corrections to your Gerrit that has not been merged. The right method for that is to amend your commit with the same ChangeId. This method is primarily useful for building on *someone else’s* commit that has not yet been merged

You are in ‘detached HEAD’ state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

git checkout -b new_branch_name
HEAD is now at 261f59d... Fix for bug 24.

As it turns out I’m not on any branch right now, because I’m on a detached HEAD:

localhost:controller hagbard$ git status
# Not currently on any branch.
nothing to commit, working directory clean

Since I’d like to be able to wander off an work on something else and still get back to my work here, I follow the helpful
advice from Gerrit and create a topic branch: