Random blurps

Moved to Wordpress

2009-12-22T15:20:00.001-08:00

The last post was about the last thing left over from my job at Pramari.
With my switch to Senacor I also decided to change my blog.
The new one is here:
http://codepitbull.wordpress.com/

WCI 2009 talk about CEP

2009-09-02T02:01:00.001-07:00

I am giving a talk at the WCI 2009 titled "Taming the Tsunami - Tackling the exponential growth of sensor data using ESP/CEP". As one might have guessed it's about my (current) favorite topic: CEP and its applications. It's going to happen on Friday October 16th, 2009 and I am pretty excited as this is my first conference submission.
For those who can't attend or want to get a little information on CEP I put the paper up on my dropbox.

Faster developing in OSGi with '-console' and 'update'

2009-08-12T06:24:00.001-07:00

Just a little hint for those who work with OSGi on a daily basis.
Starting and stopping an OSGi-framework takes time, even for small projects. Working on a bundle that requires a lot of playing around can become quite painful when you have to wait those precious 5 seconds or more until the system is restarted.
Thankfully the OSGi-spec already provides an update facility.
Each bundle can be told to update itself from the location it was loaded from.
That last part is the important part and made my life a lot easier.
Most, if not all, OSGi developers already use the console to get handy commands like 'ss' or 'services'. Another nice command is 'update <bundleid>'.
The cool thing about 'update' is that even bundles you included from your workspace can be used.
Just fire up the framework with the '-console' parameter and whenever you changed something in your workspace use update to get those changes into your running framework.

Embracing Groovy

2009-07-28T02:26:00.001-07:00

Actually it's not that much about Groovy than it is about scripting.
After a yearlong battle I finally got my way and we added scripting capabilities to the Rifidi Emulator.
Scripting became an important issue as the scenarios we wanted to create grew more and more complicated.
Now that we also have to support RSSI (Received Signal Strength Indication) we need to be able to simulate tons of different reads with varying tag properties. Something that simply wasn't possible in TagStreamer.
So finally the management agreed that we had to include scripting support.
I already had quite clear picture of what I wanted to achieve and how the thing should look in the end.
So here is a quick outline how Groovy got hooked up to the emulator.

At first we had to get rid of the PlugIn-Registry from Eclipse. We were using extension points to register the different reader implementations but decided to be OSGi compliant a while back. We ripped out the registry and replaced it with OSGi-Services and Spring.
The nice guys at Groovy were kind enough to already ship an OSGi-enabled jar. So I just downloaded the current binary distribution and put groovy-all.jar into our target platform.
We took our RMI interface that we had added to allow TagStreamer to use Emulator instances remotely and refactored it a little.
We basically made it more scriptable by exposing a couple of helper functions for creating tags and managing readers.
Integrating groovy with the new interface was the easiest part:
Using the executor pattern we start a new Groovy Shell for each script. Each script gets a reference to the reader management service injected and can now create/destroy/start/stop... readers and tags.
Now to the part that I like the most:
We have been using the Equinox-OSGi-console for quite some time now and we love how extensible this little bugger is. We added a couple of new shell commands to manage the scripts.

That's it. 5 days of work and we got full scripting into the emulator. It's not perfect but it will be improved while we use it.
Things we need to work on:

Integrate with Eclipse (We want to make use of the great tooling Groovy has there)
Integrate with Edge Server UI.
Start distributing scenarios.

But for now I am quite happy with what we got :)

Exporting an OSGi application from Eclipse

2009-07-21T16:04:00.001-07:00

Sometimes working with Eclipse feels like arcane science.
Creating a pure OSGi (Equinox) application is as easy as it can get.
Running and tuning are dead simple. Manipulating the runlevels works like a charm (needed to get load time weaving integrated).
But then try exporting it.
After a little painful research and some nice hints from the newgroup I got the following process:

Create a product from your launch config.
Open the product and go the configuration-tab. You will only see the bundles that were designated to be auto-started at a certain level. Add all other bundles and set them to auto-start at level 4. The funny thing here is that these are the default settings for every OSGi-Framework application, but in a product the default is to not auto start anything.
Now make sure that all fields on the overview-tab are blank (Application has always a preselection, at least on my install)
If you haven't done so before add org.eclipse.simpleconfigurator to be started in level 1.
Start the Export Wizard.
Make sure that "Synchronize before exporting" is UNSELECTED, otherwise the export will fail.
Export.
If you don't have the delta in your target platform you will now have to copy the native fragments into the export.

There you go.

Living without friends sucks

2009-06-29T04:41:00.001-07:00

And again I stumble over a scenario where it would be so absolutely helpful to have C++-like friends in Java.
Again I need to jump through hoops to get the desired behavior.
I am working on an integration of our SAL (Sensor Abstraction Layer) with Esper.
But the messages from SAL can go to other receivers like JMS, too.
The problem comes form the fact that the messages coming from the SAL have to be readonly to not mess Esper up.
As I like my code easy readable I prefer setters over big constructors. But in this scenario setters would be very problematic as they would allow the manipulation of data at any point in the future. Something that must not happen from the moment on the message went into Esper.
So public setters are a no go. Protected setters don't work as they are only accessible from the same package. So I end up having to write a big constructor, collect all the data from the different sources and then create the object.
Exceptions might be another way of solving the problem. But all the boilerplate code ...
Wouldn't it be nice to declare it protected and define a list of friends who can access it?
Then I would be able to create the object, pass it to the friends who are allowed to access the setters and then put the object into Esper without having to worry that somebody messes up my messages.
So sad.
Note:
I put together a little idea using CGLib and a set of different interfaces to built a proxy based solution. As soon as I get some time I will post it here.

K.I.S.S. and the 5 rules of laziness

2009-06-25T10:24:00.001-07:00

This article took me a lot longer than I had expected.

I could try to bring up the usual excuses like "my apartment exploded", "my dog (that I don't have) ate my laptop" or "my boss locked me up in my office until my Trac issues were all closed".

Nope, the problem is that simplicity is the frickin' most complicated thing to explain.

I tried to keep it simple and summarize things that I feel are important aspects of simplicity. The resulting article is not even close to what I had intended and I think I have to live with not being satisfied with the result. But at least i lived up to my promise to deliver this.

How often did somebody use K.I.S.S. ("Keep It Simple, Stupid") to tell you how to improve your code?

After using K.I.S.S. on a lot of fellow coders over the years I thought it should be a quite simple task to explain.
Let's cut this short: I was wrong.
There is so much more to this issue than you think in the first moment. Explaining K.I.S.S. would easily fill a ton of books without really getting to the point.
After a lot of discarded posts I remembered a quote from a friend:
"The most important attribute of a good developer is laziness."
Good coding skills in combination with laziness leads to effective simplicity.

So here they are:

My 5 Rules Of Laziness.

Be lazy: Look, the world is full of developers, you are most certainly not the first one to run into that particular problem. Search for an open source project or some sample code that fixes your problem at hand (Never ever forget to give credit to the source of your solution!).
If 1. failed remember being lazy: Ok, so your google-fu is weak. Most likely you will have several possible ways to get the job done. Always pick the easier route.
If you are working on 2., be more lazy: This is a lesson learned from doing projects in an agile way:
Solve your problems at hand (the ones defined for the current iteration), not the ones that MIGHT occur. Don't forget about the MIGHTs, put them as issues in your tracking system. Discuss them BRIEFLY with your project lead to see if you can replace the MIGHT with a WILL see if it is urgent enough to put in the current iteration. If not, leave it.
If you are impressed by the beauty and complexity of your code:
- Print out a copy of it.
- Put it on the wall next to the picture of Picard.
- Start refactoring until you feel like your cat could understand the code.
Document it!

1 is quite self explanatory. If you can have somebody else do your work: Have him do it.

2 is a little more interesting. It deals with the arch enemy of of software developers:

Complexity

It's a mythical beast more vicious than Grendel and sneakier than Loki. It is secretly plotting to turn your beautiful source code into a pile of gibberish.

Every software development project has the tendency to grow bigger and more complex. The accomplices of complexity (customers, management, team colleagues) are lurking everywhere. Through feature requests and performance improvements they will make your code more complex. But you don't have to make it worse.

If you can pick and choose always go for the solution that is easier to implement.

If you need to do sorting and you can choose between different algorithms: pick the simplest one. If that proves to be a problem swap it out later on (you should be using something like the the strategy pattern anyway).

Note (let's not talk about why I have to point this out):

Don't take shortcuts (singletons, declaring things static, breaking the separation of concerns principle....).

My 3rd rule is actually an extension of 2. A lot of times you will discover new problems while you are working on your items. If you find something that breaks the software RIGHT NOW:

open an issue
tell the project lead
fix it.

If it MIGHT be a problem there is a 80% chance that it will never actually happen:

report it
discuss it
If you can still put a MIGHT in the sentence describing the problem, leave it.

An example from my personal experience:

A developer was working on a fairly simple piece of model code. After seeing that the issue wasn't resolved after 4 days of work I asked the developer what was going on. He pointed out that the code for adding and removing items to the model wasn't threadsafe, so he started making it threadsafe. He had turned the whole thing into an intricated (an adjective that should make all your warning lights light up at the same time) piece of threadsafe beauty. At least that was what he thought.

The model class was used exclusively inside an Eclipse RCP application. Eclipse uses the reactor pattern, therefore everything is executed in the same thread.

He not only added tons of code that were simply not needed he also broke some things in the process.

My 4th rule is quite simple:

Nobody will be impressed by a complicated piece of code with the exception of the author. And he will lose the love for that code when he has to go back and understand it a few weeks after he wrote it.

Just remember that somebody will have to maintain it. And it will most likely be yourself.

Number 5 I just threw in because without documenting your code (and I mean in your code and not some fancy user docs) rules 1 - 4 are worthless.

New distinct operator in Esper 3.1.0

2009-05-19T06:02:00.001-07:00

REJOICE: Esper 3.1.0 got released yesterday and I am currently moving our code to use it.
A couple of leaks got fixed and some behavior have changed. But that's not what made do this post.
After reading through the changelog I discovered this little gem:
- A new "every-distinct" operator has been introduced to the pattern language. Very similar to the "every" operator, this operator suppresses duplicate results received from sub-expressions based on a set of expressions returning distinct-values.

Before the this new keyword got introduced I had to create a separate data window and use the following query to fill it with unique events:
insert into collectwin select * from reader as tagevent where not exists (select * from collectwin as collected where collected.key=tagevent.key)
Thanks to the new keyword I can now define a pattern for that job:
pattern[every-distinct(res.value) res = ParsedEvents]
As I am doing ALE I need the parsed events to be unique within a certain time frame. To reset the set of unique events do the following:
pattern[every-distinct(res.value) (res = ParsedEvents where timer:within(5 sec))]

This makes the whole thing a lot easier and better looking :)

Recent Activities

2009-05-12T11:11:00.001-07:00

The last few months were quite busy and once again it was my blog that had to suffer. We rewrote our whole middleware, I got into Esper, we had a big show in Orlando and I had to travel back and forth between Germany and the US.
But I didn't stop writing.
I finally pulled myself together to try write articles for software magazins. To my personal amazement it looks like as if people actually like the things I write ;)
The German Java Magazin published a 2 part series of articles on RFID and Open Source RFID tools in issues 4.09 and 5.09.
I mentioned before that I am writing on an article for the German Eclipse Magazin. The article was published in December 2008.
Yes, I know you won't be able to buy them as there are already new issues of both magazins out. I hope to be able to post links to the articles as both magazins tend to republish them online.

Software development basics

2009-04-12T18:58:00.001-07:00

Software development is my passion. I love creating code, brooding over algorithms, learning new languages or frameworks and just about everything that is related to it.

Having started to code on the C64 more than 20 years ago I can savely assume that I know a lot about the process and the required mindset for coding.

And it's exactly that mindset that I miss in a lot of coders that come out of university.

It's not there fault. Universities tend to just teach the tools, like a programming language or UML, skipping the essential basics.

I don't want to get started on how much I think it is wrong to start coding with a language like java.

What I want to get started on is the basic set of principles and rules that should be the mantras of every developer and most engineers.

So this article marks the beginning of a small series about what I think are essential rules to follow to become a good coder.

In the series I will cover the following things:

K.I.S.S.

Divide and Conquer

Premature optimization is the death of software

Separation of concerns

Buildr + Scala on Ubuntu

2009-03-15T20:33:00.001-07:00

So I got started on my Scala adventure.
Scala is a functional language and I wanted to get started with it since forever.
After playing around with it for some time I had to accept the sad truth:
The Eclipse plugin is a piece of crap.
Tons of crashes, inconsistent behavior, faulty auto-completion ....
So I had to go back to my old friend vim. The only problem was that without eclipse I needed something to do the building. I could have written some shell scripts but as we are looking for a better build system for our projects at Pramari I thought this might be the right time to do so.
Ant was no option, I already knew it and I wanted something new :)
Maven was also not an option. This tool is an abomination and if there is any tool that is able to singlehandedly make agile software development impossible then it is this monster (more rants to come, for now: If you need to dedicate a person to learn the build system you know that there is trouble coming).
After reading a ton of blog-posts I decided to give buildr a shot.
The tool looked very promising, getting scripting and building together looked very intriguing to me.
But before building the wise creators of Ubuntu and Buildr teamed up to give you a thrilling installation experience.
I have been working with Ruby on Rails for some time (Buildr is built on top of Ruby and Rake) so I expected a smooth installation using gem.
Boy, I was wrong.
It took me two days to figure out how to get it up and running.
First of all: I thought gem was a system comparable to apt-get. it's not. I tried doing gem install buildr which failed with a ton of error reports. After manually installing the required versions of rake and several other tools I ended up with a version of buildr.
To my surprise it wasn't added to a directory that in the shell path. After finding the file and calling it manually it failed with a couple of error reports.
To cut this short:
I just figured out how to get it running.
First of all: Don't try to do it from the debian gem repositories, you need to specify the version from rubyforge.
So here is what you need to do:

gem install net-ssh -version 2.0.4
gem install net-ssh -v 2.0.4
gem install net-sftp -v 2.0.1
gem install highline -v 1.4.0
gem install rubyforge -v 1.0.0
gem install hoe -v 1.7.0
gem install rjb -v 1.1.6
gem install rspec -v 1.1.5
gem install xml-simple -v 1.0.11

gem install --source http://gems.tron.name/gems.rubyforge.org/ buildr

This will give you a working version of Buildr 1.3.3.
To get builder to run with scala and java you need to specify SCALA_HOME and JAVA_HOME.
Uh, before I forget it:
Your buildfile needs to contain require 'buildr/scala' to be able to build a scala project. For some reason this line is not added if automatically creating a buildfile inside a directory hierarschy containing scala files.

Apache Commons Logging. IT'S A TRAP!

2009-02-22T20:24:00.001-08:00

Apache Commons Logging (ACL) is a nice idea when you first stumble upon it:
Develop your app using commons logging, use whatever logging backend you want to use and let the guy deploying decide what he wants to use for logging.
So far so good. I liked the idea. We are using commons logging all over the place.
Now reality hits.
Two weeks ago we started a new project. This time we wanted to do everything right and wanted to get all logging centralized. Piece of cake when everybody is using it ... which is simply not the case.
Having tons of open source libraries in there we finally had to realize that not all coders bought into the idea of ACL. Which is perfectly understandable as it adds another layer to your logging, another jar to the classpath and it takes away the logging interface you came to love over the years.
People use ACL, log4J and *shudders* Java-Logging. How do you handle that?
A while ago I read a post about a new logging wrapper. The post was incredibly misleading and bad researched so I almost dismissed slf4j. Thankfully I looked again.
slf4j was actually what we needed.
So what does it do?
It's quite simple:
It's a log syndication tool. It just collects logging output from all kinds of different sources and redirects it to your logge rof choice.
Awesome, finally someone got it right.
Using it in OSGi makes my life a lot easier. Using OSGi I could sneak in the replacements for org.apache.commons into all libraries and could also catch logging output from all other sources.
Give it a shot and please, remove ACL from your project, it's a waste of time and space.

Double Check in Java is broken .. not

2008-12-31T09:19:00.001-08:00

Coders from the C world are most likely to use the so called double check idiom at some point of their coding career. If those same coders (like me) do their first multithreaded app in java will probably run into some problems.After my first trials with java several years ago I ran into some pretty weird problems. Sometimes my nice apps would expose the weirdest behaviour. After searching around I got educated in a newsgroup.
Before I start to explain what the problem is I should probably explain what double-check is.
Let's say there is a certain object that needs to be initialized. An initialization should only take place once. Sometimes it might be required to postpone the initialization until the first use of the object (lazy init) or until certain conditions in the systems are met (service orientated architectures).
The following piece of code illustrates the naive approach:>

Test initValue=null;

if(initValue==null){
  synchronized(this){
      if(initValue==null){
          initValue=new Test();
      }
  }
}

So we first check if the variable has been initialized, if not we synchronize and check again and if this second check is succeeds we do the init work. The second check is done because another thread might have initilaized in the meantime.
The problem is that this won't work in Java. The JDK does a lot of work under the hood. On of these things is that threads can keep a local copy of variables. This behavior completely breaks double check.
That's where my story ended some years ago. I never touched it or bothered researching into it again.
Until I recently discovered atomic variables in Java and stumbled over the new memory model introduced with JDK 5.
After reading up on it I finally found the solution to fix double-check:
The volatile keyword.
Volatile indicates that the variable will be modified by several threads. This tells the JVM that threads are simply not allowed to keep local copies of variables.
Fixed double check locking looks like this:

volatile Test initValue=null;<br />if(initValue==null){<br />    synchronized(this){<br />        if(initValue==null){<br />            initValue=new Test();<br />        }<br />    }<br />}

Yep, I got my double-check locking back but there are still some things to consider:

Performance: If using volatile on a variable better do some benchmarking.
JDK 5: Yep, volatile only works like this with JDK 5 and later.

Spring, @Comparable, OSGi, Eclipse RCP in Eclipse Magazin

2008-12-10T04:22:00.001-08:00

I wanted to post how I got Spring to use AspectJ for DI in Eclipse RCP applications. The post won't happen as I wrote an article about it for the German Eclipse Magazin. As soon as the article is out you will find a link to it in here.

JAXB vs Interfaces

2008-11-27T04:30:00.001-08:00

A more detailed post about my battle with Spring (I WON) will follow soon.
Right now I want to talk about some JAXB stuff.
JAXB is our tool of choice to store scene descriptions to a xml file. We are not working with a predefined schema but with annotated classes.
After all the trouble that people gave us by including a (IMHO) outdated version of JAXB in earlier JDK 6 versions (Note: There is STILL no nice way to replace libraries shipped with Java with different versoins. Is it really that hard to provide Java with some hooks that would allow developers to do that??) we were very happy when JAXB 2 finally found its way into later releases.
But that's where the happiness ends. Don't get me wrong JAXB is a nice tool to handle lot of different scenarios. But why the hell did they have to make it so complicated to use interfaces?
If you start googling for 'JAXB and Interfaces' you will find a ton of people having problems to get this to work.
One of the first links you will stumble over is probably this one. A nice round up of the whole issue.
But still.
Right now I need to annotate a class in Designer using @XmlElement(Object.class).
The reason is that I need to keep a reference to a class that implements a given interface. I can't assume that the interface is implemented by a certain class.
I can think of several reasons why this is a problem for an xml-file but there has to be a nicer way to do this.

Fragments!!!!!!!

2008-11-24T16:56:00.001-08:00

Another hard lesson learned.
In my quest to get Spring-DM plus Equinox plus @Configurable to run the following fact almost killed the remains of my sanity:
A plugin and its fragment need to be in the same directory for equinox to actually aply the fragment.
So, if you, like me, are a person that likes to keep things nicely separated into different directories you are screwed.
I battled for hours. In an act of desparation I copied everything into one directory (thereby destroying my nice targte-platform-structure) and suddenly it worked. I sorted out my stuff and finally came to this conlusion.
Yeah, seems that I got everything running by now.
*sigh*

OSGi + Spring = ?

2008-11-23T03:36:00.001-08:00

It took me a while to get back to my beloved Spring.
Before I start raving about this great framework some intro why I am doing this.
Dependency Injection is one of my most beloved patterns. It removes a lot of boilerplate code from your software if correctly applied.
When we started the Designer project we were looking into spring-osgi but decided to wait for the first final release to incorporate it.
Lookign back I don't know if that was the best way to go. We had to implement our own DI-Service in OSGi. So far it has worked pretty good but with a growing project you want get rif od as many headaches as possible.
One headache is that now almost all aspects of Rifidi are using our custom DI-Service and that means we have to deal with new features (unbelievable, some people really want software to evolve).
It would be great to get replace it with Spring-DM (the Spring OSGi project).
So today is the great day:
I will try to get services injected into an eclipse view.

Things accomplished this morning:

Target platform is up and running (will be up in Rifidi subversion as soon as I am done fighting with it)
Services get deployed to OSGi
Dependencies get injected (right now using xml config files)

Next steps:

Get AOP up and running.
Inject services using annotations
Get a view injected with a service

JAXB vs OSGI

2008-03-26T16:54:00.000-07:00

A side note to those poor souls who have to get JAXB running with OSGI:
It works, but it is ugly.
A little story about the problem:
We have a ton of classes implementing different interfaces.
After putting a lot of work into refactoring the first release of designer I had created a ton of new interfaces.
We came to the point where we wanted to save all those nice classes with all the nice interfaces they implement to an XML file.
Since JDK 1.6 update 4 JAXB 2 is included in the JDK and we figured it might be good to give it another shot.
To make it short: as soon as one of our properties had an interface as its type the saving failed.
We followed the instructions on this site but JAXB kept telling us that it is unable to handle interfaces.
After some fiddling in a sandbox and reading through some osgi stuff I finally found out what to do:
Add the following JVM parameters and you are good:

-Dosgi.compatibility.bootdelegation=true -Dorg.osgi.framework.bootdelegation=*

It's a little brute force to do it this way and you will have a small performance impact on your app but at least it works.

Chopped off arm, body is healthy

2007-11-24T22:59:00.000-08:00

Yep, it was a very, very hard decision.
Today i finalized the removal of Common Navigator from Designer.
Probably one of the toughest decision I had to make so far.
CNF is an awesome framework but the lack of good documentation makes it quite a task to use it.
I got everything to work, with one exception:
Non objectContribution contributed actions.
Getting your actions to show up in the CNF popup based on the selected object(s) is a piece of cake.
Everything else is a completely different story.
I followed the instructions on digital paper napkin up to that point of adding stuff using action providers.
And there it failed. I dodn't know what I did wrong, I got the demo sourcecode, got the same exception: "Incorrect number of expressions: enablement in navigator extension: null in plugin"
A quick googling showed me that some other people hit that problem but no answers so far.
That did it and for now we will live without CNF.
I still hope to get it back in some time but right now we are back to old fashioned RCP.

Leg, Arm, Head

2007-11-20T21:56:00.000-08:00

What would you be willing to lose?
I am sitting here, after weeks of coding with the CommonNavigator framework in eclipse, just to realize that I might have to completely remove it or lose the last tiny shard of sanity left in my head.
Yes, CommonNavigator is awesome, somewhat.
The absolute absence of debugging help in it is just frustrating.
Not knowing what is wrong with your XMl and not getting any help from eclipse is rather frustrating.
By googling a little you will discover pretty soon that I am not the only person who is unable to get actions to show in the places you actually want em to show up.
By now I think I got a pretty good grasp on eclipse and the dreaded toolBar/menuBar-paths.
I even understand how the objectContributions work.
But the vieweContribution stuff is a complete mystery to me.
Seems like as if I will have to read some source code to figure out what I am doing wrong.
Would it really be that hard to provide some help in the logfiles for that?
What about adding just some lines that tell me where actions end up.
Or *ghasp* what about giving me a warning if I declare an invalid path?
So right now I have to come to a decision:
Keep CommonNavigator and all the nice goodies OR
cut it out and do it in a clean RCP-App.
And my frustration will probably lead to the latter one.

Restart

2007-11-14T23:07:00.000-08:00

Ok, it took a while and I am the king of procrastination.
But now all my excuses are gone.
Got my diploma, got rid of a lot old burdens and started with a lot new things.
I am still working for Pramari, LLC and I intend to use this as my developer blog for my current projects.
Right now I am working in three areas of coding:

Eclipse: the good stuff (CommonNavigator, yeah)
OpenGL: mostly jMonekEngine
Android: just for fun

Eclipse and OpenGL I currently use for RiFiDi-Designer which I am working on full time with my team for Pramari, LLC.

The voice job in the video is done by Prasith, the manager of Pramari.

How to get a navigator view in RCP

2007-07-28T12:50:00.000-07:00

I am struggling with the Common Navigator Framework right now.
After finding a good tutorial on CNF I started hacking away.
The problem was that I needed a navigator view to actually do something with my fancy new CNF.
Creating the view is only half the deal and after some google research I finally found the part that was missing:

In your perspective add the Navigator View


IFolderLayout topLeft= layout.createFolder("topLeft",IPageLayout.LEFT,
0.25f,layout.getEditorArea());
topLeft.addView(IPageLayout.ID_RES_NAV);

And now for the part that I was missing.
In your WorkbenchAdvisor (normally called ApplicationWorkbenchAdvisor if you used the PlugIn wizard) overwrite the preStartup method and add the following line:


WorkbenchAdapterBuilder.registerAdapters();

Uh, I almost forgot about the dependencies:
org.eclipse.ui.navigator
org.eclipse.ui.navigator.resources
org.eclipse.ui.ide
org.eclipse.ui.navigator

First post

2007-07-27T11:26:00.000-07:00

I finally did it.
My first blog.

Err, yep, enough applause.
This blog will basically cover my daily work as a software developer.
I want to provide, hopefully, useful information on java and eclipse RCP.
I realized, after fighting for the 10000000 time with some eclipse issues I had solved a year ago, that it would be great to keep track of these things and probably help some people who might stumble upon the same issues.
About myself:
I am a software developer currently working for Pramari, LLC.
We are developing java based open source software (for those who want to know: we are working on a RFID simulation environment called RiFiDi).
I am currently developing a 3d simulation that incorporates jMonkey and eclipse.
And another side note:
I am German, so English is not my native languag, I am a fluent speaker but when it comes to written language I might have some weaknesses. If you find misspellings or grammar problems feel free to send me a note.
Thanks
Codepitbull