Osmorc

I have created a small demo video which gives you a quick tour around Osmorc. It explains a basic project setup, the Osmorc facet and how to create run configurations to run and debug OSGi bundles from IntelliJ. It does by far not cover all things to know about Osmorc, but it should give you a nice start.

Please provide feedback about the video, as this is my first try on such stuff and there are probably a lot of things to be improved in further videos. Looking forward to your comments.

Link: Osmorc Demo Video

After a lot of work we finally pushed version 0.6.0 of Osmorc out to JetBrain’s plugin registry. This new version comes with a lot of added functionality, most notably:

• You can now build, run and debug your OSGi bundles directly inside IntelliJ. This works so far for Knopflerfish and Apache Felix (Equinox is scheduled for the next version).
• The bundle’s JAR file is built automagically with IntellIJ’s internal build tool when you build a OSGi-enabled module.
• Osmorc can automatically manage the Manifest file for you (imported and exported packages, etc.). We have integrated the well-known and rock-solid bnd tool for this. In case this is not working for you, or you prefer total control, you can still manage the manifest file manually.
• Framework classes are made available to your project once you select an OSGi framework to be used with your project.
• Osmorc should now work a lot better with existing build scripts in Ant/Maven. You can specify where Osmorc should put the Jar file, where the Manifest file should be placed, etc. So now you don’t have to decide between using the internal build for faster roundtrip and your external build for added flexibility - just mix and match as you see fit.
• You can now report bugs directly inside IntelliJ using the newly created OsmorcIssueSubmitter plugin. We decided to create a second plugin for this as the issue submitter is unlikely to change very often and we’d like to keep the download size small.

And of course - guess what - we fixed a ton of bugs. We think that this release should enable you to productively develop OSGi bundles in IntellIJ. So how about firing up your IntellIJ and downloading Osmorc 0.6.0 right now? We look very much forward to your feedback and suggestions for the next version!

Well, it has been 3 months since the last release and I feel the need to explain why the next release takes so long in coming.

Unfortunate cicumstances on my part - I had to undergo surgery two weeks ago and had to return to hospital a week ago because of some complications that came up a week after the surgery - are currently hindering me to make the finishing touches and roll out 0.6.0.

I’m optimistic though, that I will be able to finish my work on Osmorc for the next release by the end of next week and that we’ll have a release out at the beginning of August.

Sorry for the inconvenience to all of you waiting for a new release.

First the big news: Osmorc isn’t a one-man-project anymore. Jan Thomä joined me and is currently developing the part of Osmorc that will enable starting OSGI applications from IDEA. The code he already committed into the Subversion repository looks very good and I surmise that it won’t be very long till an OSGI Run Configuration can be created and executed.

I’ve implemented error reporting for Osmorc, so the “Blame OSMORC” button will be enabled in the next release and will make error reporting much easier. Currently I’m working on creating modules for framework instance libraries. This will make it possible to search for classes in the framework instance via CTRL-N. Currently you will only find classes from framework instance bundles that an application bundles depends on. After this is finished you will be able to find any class in any framework instance bundle — no matter whether an application bundle depends on it or not.

Today I released version 0.5.0.

It is mainly a maintenance release fixing some nasty bugs reported by users.

I also added some more documentation that should give anyone new to Osmorc an idea how Osmorc works and how to get started with it. The documentation is far from finished and I will add to it with each new release. It’s probably typical but I just cannot spend two weeks or something like that with only writing documentation. It would kill me - sort of.

Please take a look at this version in JIRA for a list of fixed issues.

The ZIP for 0.4.0 which I uploaded to plugins.intellij.net had a bad folder structure. I have uploaded 0.4.1 which fixes this problem.

Finally after two months of development I’m pleased to release the next update of Osmorc.

The big new feature of this release are framework instances (a.k.a “target platform” in Eclipse). For the creation of framework instances three OSGI implementations are supported out of the box: Eclipse Equinox, Knopflerfish and Apache Felix. The framework integrators for those implementations take care of collecting all bundles and their sources from an installation folder. Please read the also newly added documentation which is available through IDEA’s help system to learn about specific constraints for the different implementations.

One known issue is that when you add a framework instance (See File | Settings | Project Settings | Osmorc) and directly choose it for the current project, the dependencies on the then newly generated global libraries are created and can be seen on the “Module dependencies” page, but they don’t appear below the Libraries node of the modules in the project view. A work around for this is to first define the framework instance, apply the settings and then reopen Osmorc’s settings dialog and choose the framework instance for the project or to simply close and reopen the project.

Also new is the autodetection of the Osmorc facet when an existing manifest file contains the Bundle-ManifestVersion and Bundle-SymbolicName headers. On the other side when an Osmorc facet is added to a module without a manifest file a manifest file is generated for it.

The road map has changed a bit. Adding run configurations has been pushed to version 0.6.0. In version 0.5.0 I will try to fix an inconvenience concerning framework instances. Since global libraries are created for the bundles of a framework instance and dependencies from modules to those libraries are added when the corresponding bundle is required or one of its packages is imported, there’s no easy way to see which bundles are available in the chosen framework instance. A solution I will investigate for 0.5.0 is to create wrapper modules for the global libraries of the framework instance used in a project.

Currently I’m working on a feature that allows the definition of framework instances. A framework instance is very similar to a target platform in Eclipse. I chose to call it a framework instance because it not only defines the collection of bundles that are part of the used framework and on which the application being developed depends. It also defines which framework integrator is to be used. Those framework integrators know how to handle specific tasks — like collecting the needed bundles — for a specific kind of framework. Some tasks will be handled quite differently whether they are executed for Equinox or Knopflerfish for example.

Currently there is a framework integrator for Equinox, but once I get the bundles from an Equinox installation integrated into a project depending on it, I will implement framework integrators for Knopflerfish and Apache Felix.

The next version — 0.4.0 — will allow you to define framework instances for any of those OSGI frameworks. Dependencies on framework bundles will then be fully resolved and applications should be compilable without any dirty tricks like defining a global ECLIPSE library and making each module of the project depend on it.

There are already plans for the version after 0.4.0. For version 0.5.0 I plan to add the possibility to run and debug OSGI applications from IDEA.

I cannot give any specific release dates, but I hope to get 0.4.0 out in the first half of March.

This release of Osmorc integrates Eclipse Equinox which is used to resolve bundle dependencies. Now versions and other constraints are taken care of. Thanks to Gerd Wütherich for pointing out to me that Equinox can be used outside a running OSGI system for this purpose.

With this integration the further roadmap changes a bit. Before I was working hard to get the whole manifest parsed. While this is still an important feature to me, it isn’t top priority anymore. The next task on the list is to get definition of a target platform working. As soon as that is achieved, Osmorc will start to be really useful for real-life projects.

Afterwards I will return to parsing of manifests and will provide more cross-referencing and more error recognition and quick fixes.

Note: Integrating Equinox doesn’t imply canceling support for other OSGI implementations. The support for specific implementations will become apparent the first time with the added ability to define a target platform.

Up to version 0.2.0 Osmorc was in a what I’d like to call exploration phase. There was an idea, a platform to realize it on — IDEA’s OpenAPI — and an ambitious developer — that’s me ;) To the delight of the ambitious developer the idea was realizable and diligent trying and guessing was awarded with visible progress.

Testing in that phase was done manually. I coded something and started IDEA with an activated Osmorc plugin to see what effect that coding had. This kind of testing is OK for an exploration phase where the developer doesn’t know what the exact results of his doings will be, but now that I know how the parts of the API I’m using are generally working — some surprises still crop up now and then making sure life stays exciting — automatically running tests are really needed.

So now I started expanding the collection of JUnit tests. I finally took the time to look into IDEA’s testing framework. At first it all looked quite complicated. But then I realized that I did not need to subclass any of the provided JUnit 3 TestCase subclasses. The only thing needed for a working test environment with working IDEA singletons is a fixture that can be created pretty easily. There is also a lightweight version of that fixture that works in memory only. With that lightweight version I have created among others tests for the parsing of manifest files.

For the next tests I want to write, I’ll probably need the heavyweight version of the fixture. Those tests will test how the dependencies between modules are arranged based on the settings in the manifest files. Currently I have some problems getting this to work. Strangely I am not able to add more than one module to the heavyweight fixture. For dependency checking you need at least two of them.

Some work has been done on version range parsing and I introduced a new concept — value parsers — that will make it possible to parse values of specific types no matter where they appear with correct annotations and quick fixes for parts with errors.

Today Gerd Wütherich one of the developers of Ant4Eclipse emailed me pointing out that I can use Equinox to resolve dependencies between bundles without having to run it as an OSGI runtime. The current implementation in Osmorc is a very simple one that doesn’t take versions or any other constraints into account. A first look into Ant4Eclipse and into Equinox revealed that I will most likely be able to use it in Osmorc.

So the plan for the next two weeks is to get heavyweight tests working with some appropriate tests and to integrate Equinox for bundle dependency resolution.