December 2007 Archives

Nice, I’m on my Christmas vacation now. That means that I have lots of time to sleep, read some good books, listen to music and of course to work on Osmorc. So just before The IntelliJ IDEAL Plugin Contest closed, I released version 0.2.0 of the plugin.

As already mentioned in the previous post, I fixed a bug that prevented Import-Package and Export-Package in Osmorc from working correctly. This bugfix is included in this new version.

I also implemented version parsing for Bundle-Version. If something in the major, minor or micro component is wrong the erroneous component is annotated with an error message. I still need to implement version range parsing and use both of them everywhere a version or version range is used.

I’ve also made some changes to syntax highlighting. The lexer now uses specific token types for attribute and directive names. So they now get syntax highlighted, too. I added a settings page for the colors and fonts used in manifest files. Now you can change the default theme. The default theme uses very few colors. You can add specific colors for header, attribute and directive assignment signs as well as for clause separators and parameter separators.

Unfortunately the first release of Osmorc — 0.1.0 — contains a bug that prevents Export-Package and Import-Package from working properly. It only works for simple packages like “foo” and “boo”, but not for “foo.boo”. While my test project for Osmorc was sufficient for testing Require-Bundle, it apparently wasn’t for testing those two headers.

It’s already fixed in the Subversion repository and the fix will be part of a new release on Thursday or Friday.

I’ve been a bit unspecific about what Osmorc currently does. I’m now going to change that and talk a bit about what currently works and how.

When I started thinking about Osmorc — back then the working title for the project was OSGIDEA, but I dumped that, because it had several disadvantages I might talk about in a later post —, I first thought that the way to do it would be to somehow run some OSGI implementation — Equinox was the one I was thinking about — in the background and somehow connect it to IDEA and somehow inject it’s dependency concept into IDEA. Unfortunately there were to many somehow’s in there and that just didn’t get replaced by some concrete how’s.

So OSGIDEA went to sleep before becoming anything more than the idea, that it would be nice to be able to develop OSGI applications in general and more specifically Eclipse RCP applications with IDEA. I then ventured on other paths and developed the FileBrowser plugin for IDEA.

Then some day it hit me that there is no real need to have that background OSGI running to be able to develop OSGI-applications. OSGI defines a big framework of services that are needed while an application based on it is running. There’s lots of classloader magic and other tricks that aren’t relevant during development.

The biggest prerequisite for the development of OSGI applications is that the module layer part and how it defines the dependencies between bundles works in the IDE. If that works, it prevents you from using classes inside a bundle that aren’t available to that bundle, and provides the classes that you may use in a given context.

The easiest thing to implement in the plugin was Require-Bundle. It directly corresponds to a module dependency in IDEA. That’s fairly nice and easy. Once you add the Osmorc facet to an IDEA module Osmorc takes over module dependency handling. It will remove dependencies to modules of bundles that aren’t required by it and will add dependencies to modules of bundles that are required. So: Don’t play with module dependencies in a module where Osmorc is activated. It won’t do any good. You can and should add library dependencies to your modules since Osmorc doesn’t handle Bundle-Classpath entries yet. Note that Osmorc looks at Bundle-SymbolicName when searching for bundles with a specific name. The module containing a bundle can have any name. It isn’t considered by Osmorc.

Import-Package is a bit harder. Osmorc searches for all bundles that export the needed package and adds the containing module to the module dependencies of the module containing the importing bundle.

Now the third part: Export-Package. That’s the hardest one and it cannot be handled by changing module dependencies. When a module has a dependency to another module, it has access to all public classes of that module. That’s where Osmorc’s “Invalid Import” inspection enters the stage. It is activated by default and shouldn’t be deactivated since it is a vital part of Osmorc. This inspection marks any import or other use of classes and packages that is invalid due to dependencies defined in the bundle manifests as errors. Since inspection errors cannot prevent a compilation from succeeding, IDEA will even compile classes with such errors. You can do a full project inspection analysis before deploying your application to make sure that it uses no invalid imports.

The obvious weakness of this approach is that there are situations that work with OSGI but won’t work with Osmorc. Imagine the following construed situation:

Bundle xmas contains and exports a package gift which contains a class Toy. Bundle easter contains a package gift which contains a class Toy. easter doesn’t export the package gift, though. It exports another package named bunny. Bundle holiday imports the packages gift and bunny.

AFAIK that is a totally legitimate situation for an OSGI application and any correct OSGI implementation will handle it correctly. Osmorc won’t handle it right. Depending on what module appears first in the module dependency list, the implementation of Toy that is contained in easter or xmas will be used by IDEA. This becomes apparent when the signatures of the used methods differ in the two versions of the class. You can fix this by changing the order of the modules in the dependency list. Osmorc currently doesn’t change the order of modules in the dependency list of a module. It only adds new modules and removes modules that a module doesn’t need to depend upon anymore. But obviously that also has its limits.

My current answer to that is: “When your application contains such situations, then something with it is wrong.” It just looks strange to have two versions of the same class in two different bundles like that. I can think of no situation in real coding life that looks like this and makes sense. I’m interested to hear from anyone who can provide real examples that look like this.

OK, what’s more in Osmorc? When you open a manifest file, you’ll notice that it is syntax highlighted. Osmorc contains a custom language implementation for manifest files. The syntax highlighting is a bit sparse as of now, but that will be improved upon in the near future. There’s auto completion for packages in Import-Package and Export-Package. You can CTRL-click on packages in those two headers to jump to them. You can also CTRL-click on bundle names in Require-Bundle to jump to the corresponding manifest file. And there is an inspection that checks the case of header names and proposes to correct it if it doesn’t match with how it is defined in the OSGI specification.

OK, that’s all for now. Stay tuned as Osmorc evolves.

So now the first release of Osmorc, the plugin that enables development of OSGI based applications in IDEA is available in IDEA’s plugin repository.

In this first release only the basic connections between bundles via Export-Package, Import-Package and Require-Bundle are implemented. Version checking isn’t done yet for example. In it’s current state it’s somehow a proof of concept, that OSGI support in IDEA is possible.

IDEA modules don’t allow to export or import only specific packages. The pragmatic way taken in Osmorc is to create module dependencies to all modules that export any of the needed packages and to use an inspection that will mark any invalid imports and usages. Surely, there are situations that are possible with OSGI but won’t be possible or will produce strange effects in Osmorc, but I think that most cases will work with this pragmatic approach. Let’s see how far we’ll get with it.

My plans for this plugin are big. Currently I’m envisioning support for the development of Eclipse RCP applications, but I’ll do baby steps here. There’s still much to do in the basic OSGI support area.

Osmorc is a plugin for IntelliJ IDEA I’ve been working on for the last couple of weeks. It enables the development of OSGI-based applications in that IDE.

This is just a rough site for now using Movable Type’s default style. It will be changed in the near future to use an own design.

Stayed tuned for more information about the plugin when it gets released in a few days.