JAXB vs Interfaces

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!!!!!!!

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 = ?

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:

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

Next steps:

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