Results tagged “details” from Osmorc

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.

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.

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.

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.