If you use Eclipse to develop OSGi based applications you may use the OSGi Launcher provided by the PDE Tooling. It’s cool tooling because it gives you full control over the OSGi instance to be launched.  You can choose the OSGi framework (e.g. Equinox or Felix), select the bundles to install and much more.

But this launcher has one drawback that hurts every time I run across it. It appears when an OSGi application uses the OSGi HttpService. When you used this service you may have configured a port for it via the property “org.osgi.service.http.port” VM Argument.  I use this configuration all the time.

When I launch the application everything works fine the first time. But, during development I often come to the point where I need to relaunch the application. When I forget to kill the previous running instance I get a java.net.BindException because the address is already in use. So, to fix this I have to kill both instances and launch it again. This happens to me a lot just because I forget to terminate the previous instance. Of course this isn’t a bug because it’s often useful to launch a second instance of the same configuration. But, not when it comes to developing with the HttpService.

There is a fix now (though not necessarily for my forgetfulness ).  Luckily we live in a modular world in Eclipse. As a result, I was able to develop a separate bundle called the “OSGi Eliminator” (what a descriptive name ). The bundle contributes the functionality to automatically terminate a running OSGi Instance when you try to launch the same instance a second time. This functionality already existed in the RAP launcher created by Rüdiger Hermann. All I did was to refactor the functionality out to make it run in a separate bundle and contribute to the OSGi Launcher instead of the RAP Launcher. This solves an annoying problem for me – maybe for you as well?

You can find this bundle on GitHub. I also created a p2 repository that lets you install the OSGi Eliminator directly into Eclipse.

• p2 repository: http://hstaudacher.github.com/OSGi-launcher-enhancements/
• git repository on GitHub: https://github.com/hstaudacher/OSGi-launcher-enhancements

Tags: equinox, felix, GitHub, httpservice, OSGi, pde, rap, rtp

A while ago I introduced you to my Google Summer of Code 2010 project, the WAR Products. I really appreciate your participation with feedback and bugs. It showed me that there is a real need for this tooling, so I’m proud to announce that the WAR Products development will not continue in the RAP Project.

You may think, “WTF? Odd thing to be proud of.” But, it really does make sense . The WAR Products were never targeted to be part of RAP, primarily because the tooling is not RAP specific. It eases the deployment of Server-Side Equinox applications. And this kind of application does not necessarily have to be a RAP application.

Three months ago a new Eclipse project was announced. It’s called Libra or formerly “OSGi Enterprise Tools” (it had to be renamed ‘Libra’ because of legal issues). I don’t want to repeat the project goal here because Kaloyan (the Libra project lead) does a much better job with this than I could. You can read about the project in this proposal. Libra passed the project creation review a while ago and provisioning by the eclipse.org webmasters is ongoing. So, why am I talking about Libra here?

There is a simple reason.  Because of one sentence from Kaloyan about Libra, I thought it would be the perfect project to contribute the WAR Products to.  “Libra tries to close the gap between PDE and WTP”.  This maps exactly to the WAR Products as the tooling tries to ease the deployment of Equinox-based applications on Servlet-Containers or JavaEE Application Servers.

Additionally there are plans to extend the tooling with a WTP integration to enhance the creation of a WAR Archive with automated deployment functionality, without adding explicit dependencies to WTP. And where can this development be done better than in between PDE and WTP?

Yesterday I committed the WAR Products to the Libra git repository after it passed the IP process successfully. I also set up a temporary p2 repository from which you can install the tooling (Eclipse 3.7 M4+ required). Of course we’re trying to push Libra in the direction of Indigo. If this works you will soon be able to install the WAR Products from the Indigo Repository. Please keep in mind that the bundle ID’s have changed during the move. So, if you had installed the sneak-preview from this blog post, please uninstall the tooling before installing the Libra version. It’s really worth getting the new version because of many bug fixes and enhancements which are included. Please feel free to file bugs, but this time against Libra

Please note: To use the WAR Product’s full functionality you need to add the Equinox Server-Side SDK to your target or set RAP 1.4 M5 as your target environment. There is no longer a “requiredBundles.zip” that you need. Use this temporary p2 repository to install the WAR Products: http://download.eclipsesource.com/~hstaudacher/warproducts/3.7/

Tags: equinox, gsoc, indigo, libra, pde, rap, server-side, wtp

Please note: This post is outdated. Please read this post and do not follow the install instructions in this one.

A few weeks ago I presented you my GSoC 2010 project. The idea was to make Equinox/RAP WAR deployment easier. And yes, it was a real pain to create .war files for an Equinox/RAP application. About 215 deployment related threads on the RAP newsgroup speak for themselves. But the pain is over now, and I think I can say,  “Mission accomplished”.

I want to introduce you to a new concept called WAR Products. They are similar to Eclipse Products but much more lightweight. All you have to do to export a RAP application is to create a .warproduct based on a working launch configuration and press ‘export’. The exported .war file is ready to deploy. There is a function included that validates your .war file content before you’ve exported it. If you don’t believe me,  watch the screencast below and see for yourself.

You can use the tooling right now, but please keep in mind that we are still polishing. The final goal is to contribute it back to PDE, but there are still a few things to do before we make the contribution.  One of those items is to get your initial feedback so when you use the WAR Products tooling, please be sure submit your feature requests or file bugs and help us to continue to improve the tooling.

Here is what you need to do to use the WAR Products tooling:

1. Install the tooling from this repository into your IDE: http://download.eclipsesource.com/~hstaudacher/warproducts/3.7
2. Set up your target. You need to add RAP 1.4 M5 or the Server-Side Equinox SDK.

Again, comments, bugs and feature requests are appreciated!

At this point I want to thank some people. First of all, Rüdiger Herrmann for great mentoring and the whole RAP team for all the nice evenings in the beer garden. Not to forget Simon Kaegi, Scott Lewis and Chris Aniszczyk and the rest of the Equinox and PDE teams for tuning up the Product concept. Your changes made things much easier.

And, I hope that you will find WAR deployment and creating WAR Products not just easier, but completely pain free!

Tags: equinox, indigo, OSGi, pde, rap, soc, war deployment

Even though I’ve been involved in the Eclipse community for around 5 years, I’m still amazed by the projects that are hosted under the Eclipse umbrella. As an “insider”, I have a pretty good overview of many projects and at least a rough picture of all the other cool stuff. While I love working with EclipseRT technologies like Equinox, RAP, EclipseLink, ECF or <insert your project here>, I always find myself in the same situation.  This stuff is awesome but do users really get the point of what’s possible? Learning a new technology is always hard, but if you want to develop enterprise-ready, scalable and vibrant platforms using Eclipse components, there are so many obstacles to overcome. You need to have at least a clue about OSGi/Equinox, Extensions and their corresponding Extension points (for each for your consumed modules) and many other things. I don’t want to say that Eclipse is too complicated (which is a topic for another post anyway), but what I would really like to see is a better way to get our future consumers up to speed. As Esther Dyson once said:

A worker’s paradise is a consumer’s hell.

With the Eclipse Examples project we wanted to provide a few exemplary projects to show how to use different projects. In theory a nice idea, but practically I don’t see that this effort was very successful. Wayne and me discussed some ideas back in 2008 but without a concrete outcome.  Thinking about this topic after EclipseCon, my current thought was to provide easy ways for our consumers to try out the bits and pieces of all the projects. What I constantly run into though, is that you need to do so many things  before you can get started, like setting up a target platform, making your examples depend on the right bundles, using the right extension points/services/etc, creating launch configurations. Many projects already helped themselves by providing examples using PDE templates. That’s the way I’d like to tell newcomers how to get started and would push this even a little further – the idea is to provide some infrastructure in the Examples project to help others setting up their examples. The projects just provide example bundles, maybe a target definition, a launch configuration and a cheatsheet or something. In the end, the user should be able to try out another Eclipse technology within 2 clicks: New Example > That technology, run!

Basically PDE already provides many of these things but it’s not yet at the point I would love to see it. It’s still too complex for consumers to create target platforms (I know what I’m talking about), create their launch configs and get started with the examples. While there are still some hurdles to jump, I think our users and consumers would thank us for getting them up to speed in seconds. It should even be interesting for non-OSGi related examples as other projects thought about something like this for years. I don’t see a chance to have this ready for Helios, but I’m pretty confident that we could do something like this in the timeframe for the I… release train. Would other projects be interested in such an approach to distribute their examples? Please leave a comment on this bug if you do so to collect ideas, wishes and requirements.

Tags: consumers, eclipseRT, equinox, examples, OSGi, p2, pde, rap

A nice thing about Eclipse PDE is that it has mechanisms to make it very easy for developers to get started consuming your frameworks. Here are two of them.

Target Platform Templates

For runtime projects, such as Riena, RAP and Equinox, the first hurdle a developer faces is to set-up the appropriate target platform. A target platform is the collection of bundles that are available during compilation. Obviously if you ship runtime components they must end up in there to be available for compilation.

You can make this much easier for others by contributing a target platform template to the “New Target Definition” wizard. A developer can then select an entry in the “Template” drop-down and will instantly receive a pre-configured target definition. Much easier and less error-prone that recreating the target definition manually from step-by-step instructions.

Since the target definition’s payload can be provisioned over http, the developer only has to click on “Set as Target Platform” and is done. For details refer to the org.eclipse.pde.core.targets extension point.

Project Templates

Another way to help developers with their first steps is to provide a project template. This hooks into the last page of “New Plug-in Project” Wizard and pre-populates a new project with source code, binary content and appropriate plugin.xml and MANIFEST.MF files.

The templating mechanism has a lot of depth as you can manipulate data-models to dynamically craft the MANIFEST.MF and plugin.xml files. You can also define placeholder variables, such as $pluginId$ and use them in source templates. There are mechanisms to tie these variables to UI elements in the wizard pages. The developer documentation on the matter is somewhat superficial. At the moment your best bet is to check out and study the org.eclipse.pde.ui.templates project from the Eclipse CVS (/cvsroot/eclipse/pde/ui/org.eclipse.pde.ui.templates). It contains the templates that ship with the IDE and therefore plenty of examples. Complement this by reading the specification of the org.eclipse.pde.ui.pluginContent extension point and this introductory article on developer works.

Tags: pde, tips

Lately I have been working on (and committing) a repository analyzer tool for p2.  It is meant to help you validate your repository against known problems and common mistakes (missing version numbers, two IUs with the same ID/Version, etc…).  After cleaning up the code I finally committed it.  Within a few minutes of committing it, Andrew starting pinging me to let me know I introduced a compile error. (Thanks Andrew).

The offending lines where here:

and more precisely:

You see, while this may seem fine to all you Java 1.6 developers out there, p2 is set to run on CDC-1.1/Foundation-1.1 and JSE-1.4.  I know in the Java SE space, 1.4 is long past end of life, but in the embedded space, it is still very common.  (Remember, these embedded devices require much smaller VMs, otherwise we complain that our small devices are two slow /sluggish / expensive, etc…) — and p2 is a provisioning platform that operates just fine on embedded devices.

With Eclipse, you can set your Execution Environment (EE) and point to a variety of JDKs.  This allows you to “single source” your code so the same code can run on a server with Java 1.6 installed and a small device with a Foundation VM.  However, I don’t have a Foundation VM .

Lucky for us, an EE description for several JDKs is available in the Eclipse CVS repository:

Once you checkout the project, you can add this to your list of known JREs

Now I get all the Java tooling (content assist, compile errors, etc…) for the Foundation 1.1 VMs.

Tags: OSGi, pde, tips

Whenever I’m working on UI stuff, something always goes terribly wrong Sometimes it’s only a margin or padding, other times it a composite that crosses my path. I was pretty happy that Chris Aniszczyk and Simon Archer hacked together Picasso, which helps you to identify some of these layout issues. As you may know, most of the time I work on the Rich Ajax Platform (RAP) and come across the same issues. As Picasso was originally intended to work for RCP, it’s not a long way to get it working for RAP.

In case you’re struggling with these issues too –  and working on RAP applications, please add your vote to bug 267975 so we can use Picasso on both runtimes.

Tags: layout, pde, picasso, rap, Single Sourcing, tips, ui

If you’re using Eclipse for OSGi development, there’s a neat utility that you can use to help you run your OSGi application on a variety of frameworks. PAX Runner uses the PDE org.eclipse.pde.ui.osgiFrameworks extension point to supply frameworks.

To install PAX Runner, simply add their repository via software installation wizard.

There’s an important thing to note about PAX Runner. When you’re self-hosting with a PAX Runner based framework, your bundles will be deployed before executed. This may cause launching to take a bit longer than you’re used to depending on the size of your application. This is different from the traditional PDE workflow where we don’t have a deployment step when self hosting because Equinox provides us with some great hooks to skip that process. If you’re curious how this works under the covers, PDE instructs Equinox where to look for classes for the various bundles in your workspace (usually in the bin/ folder). This is known as the development time classpath and as far as I know, Equinox is the only framework to support this type of classpath (I filed a bug against Felix awhile ago).

On the whole, I recommend you give PAX Runner a try.

Also, if you have any ideas on how PDE can better support other frameworks, come talk to us.

Tags: OSGi, pde

One of the great things about Eclipse is that it evolves, it’s not static. We reinvent ourselves.

From IDE to RCP to Runtime. From Platform to e4 (e.g., the future).

When we evolve, it gives us an opportunity to think about our lexicon.

I recently sent an email to the Eclipse PMC entertaining the idea of deprecating our usage of the word ‘plug-in’:

On last week’s Eclipse Architecture team call, I brought up the ‘plug-in versus bundle’ naming issue. This naming issue also came up at this week’s PDE team call where we had consensus that deprecating the word plug-in would be a good idea. Furthermore, the new components in PDE (e.g., API Tools) have gone out of their way to not call things plug-ins. I also know the Equinox p2 team struggles with naming problems (e.g., calling things software).

…

My proposal is that we adopt “bundle” and deprecate “plug-in” as the official module term.

If you’re interested in this, please comment on this bug. There’s also another bug open that wants to rename RCP if you’re interested in that too.

I would like to hear from the Eclipse and OSGi communities on what they think. Good or bad idea?

Would you welcome the change?

Tags: OSGi, pde

Yesterday I spent the day working on examples of how PDE Build can be used to build OSGi bundles.  I was setting up builders, copying files from my workspace to my builder, and running builds.   Early in the morning I was faced with the follow:

The method disposeImageButtonImages(ImageButton) from the type
ScaledWidgetFactory refers to the missing type ImageButton

Ok, a compile error, no big deal… the better part of a day later I finally had this solved.  Just so nobody ever has to deal with this particular error again, I thought I would post a small debugging tip you can use.  But first, some background on my day (after I saw the error):

1. Ensure export from the UI works… yes!
2. PDE/Build defines a variable called pluginPath that you can use to point at additional plugin locations.  Since the missing type  –ImageButton in my case — was in a pre-compiled bundle that exists in my target, I assumed this variable was set wrong.  I tried different separators, bundle ordering and directory locations (with and without spaces in the name). I even tried putting the bundle in my baseLocation.  No dice.
3. You can debug Ant scripts using PDE/Build.  There are a few things that you must setup first, but after I did this I was able to debug the script and ensure that the “so called ‘missing’” bundle was indeed in my classpath.
4. At this point something hit me — the compile errors is on the method call, not the import statement. That means that the compiler found the type on import, but not when the method was called…. strange!
5. In this particular example we are using Import-Package as opposed to Require-Bundle. Maybe I found a bug… I changed all the code to use Require-Bundle… No Dice.
6. Because build can be finicky, and and a typo can cause all sorts of problems, I started again… Same problem.
7. Read a story to my daughter. (Best part of the day, by far)
8. Back to work… This time, I started making small changes in different bundles, copying them over, and trying again… At one point, IT WORKED!
9. Revert the changes… IT WORKS! — Note: That’s not good
10. Start over, .. IT FAILS… make the same changes I did above.. IT FAILS!
11. Curse
12. Notice something.. when I copy the directories over, I am copying a bin/ directory that may (or may not) have fully built .class files.
13. Delete the bin/ directory .. IT WORKS!

In fact, the problem will happen very infrequently.  It only happened because I was copying bundles from my workspace (not fetching them from CVS), and in some cases, the bundles were not fully built.

So, the lesson: If you get strange compile errors using PDE Build, try deleting the bundles bin/ directory.

Thanks goes out to Andrew Niefer who once again came through with a much better way off structuring my build.

Tags: pde, pde build, tips