What works and how it works

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.