Today I had the most painful PDE headless build ever. This post just describes what I had to do to deploy an Eclipse RCP application.
The Application and Technology Stack
My application, Medmon, contains about 20 bundles. Most of the are written in plain Java (JDK 7). Some of them are mixed projects with Scala (2.9.1.final). Medmon is a simple CRUD application with an embedded derby db for backend. It relies heavily on OSGi services and uses this concept whereever possible. As data persistence layer we use Eclipse Gemini JPA and Eclipse Gemini DBAccess which provide enterprise persistence for OSGi systems. One plugin uses code generation via the Eclipse Annotation Processor, because the model is implemented with Eclipse Sapphire. Finally the Eclipse version we’re using ist 3.7.1. So I summarize the technology stack:
- Eclipse Indigo (3.7.1) with Scala IDE Plugin, Sapphire Plugin and Git Plugin
- Persistence Layer: Eclipse Gemini JPA / DBAccess, EclipseLink 2.3.0
- Scala 2.9.1.final
- JDK 7
The product
At the beginning there is the product definition. Defining this for an existing Eclipse Application and your bundles organized in Features is really simple. We added a two vm arguments:
-DREFRESH_BUNDLES=false
Prevents Eclipse Gemini from refresh bundles which causes UI extension points to randomly
disappear.
-Dderby.system.home=${system_property:user.home}${system_property:file.separator}".derby"
Sets the derby.system.home variable which is used to resolve the embedded db directory if not given absolute. The ${…} is resolved at runtime via Eclipse.
The medmon.derby plugin has a little specialty in its MANIFEST.MF
Eclipse-BundleShape: dir
which deploys the plugin as a directory instead of a JAR file.
Let’s deploy it!
Okay. I want to test in on my Ubuntu machine. Using Eclipse Export Product wizard is easy. The wizard generates a repository and an application folder. I’m now writing down every single step I had to do to run this product.
1. Redeploy all plugins with Scala code
The PDE headless build ignores the Scala compiler and just compiles all java classes. However it copies all .scala files in your JAR. If you want to or not. You have to redeploy your plugins with the deploy plugin wizard and select use compiled classes from workspace. Now you got class plus scala files in your jar. Not good but better.
2. One plugin isn’t compiled completly
One plain Java plugin didn’t have any class classfiles in its deployed jar. I had to copy it manually in the jar, where I found a bug in Ubuntus Archive Manager: If you copy a directory recursive via drag and drop into the jar file only the leaf files are copied. So I have a package x and a subpackage x.y. But only classes in x.y where copied.
3. Eclipse-BundleShape: dir – only works deploying meta-repository
If you don’t enable the „generate meta repository“ option this MANIFEST option will be ignored.
4. Placeholder in eclipse.ini aren’t translated in deployed products
The VM argument
-Dderby.system.home=${system_property:user.home}${system_property:file.separator}".derby"
isn’t parsed at runtime in a deployed product. Derby tries to create a database relative to the execution folder his folders. Change eclipse.ini.
5. Problems not mentioned or not tested yet
- Startlevel configuration via simpleconfigurator plugin.
- Multiplatform export with DeltaPack.
- Why use Eclipse-BundleShape