July 2010 Archives

Last week I started a small survey about which approach to manifest generation is more popular. The survey is still open for participation, so if you have not yet cast your vote, this would be the time to do it. The results so far:

• 88% do code first, while only 12% do manifest first.
• Top reasons for doing manifest first are: more control over the manifest, and IDE support showing non-available classes.
• Nearly all people who do code first think that a tool will do a better job creating a manifest than they would.
• Code first is also seen as less error-prone and faster to work with.

The final question provided somewhat puzzling results:

• Most of the comments suggested that it would not be a good idea to promote manifest first as it would encourage users to produce broken manifests.
• Yet again 40% voted for an improved manifest first support.

So the results are somewhat inconclusive. I was actually thinking about ditching manifest first support in Osmorc, yet it still seems to be a requested feature, apparently even by those who use the code-first approach. Then again only 17 people participated so far so deriving a trend from that would be premature.

Bottom line - I need more input. So if you haven’t done the survey yet, please do - it’s only 4 questions and probably done in a minute.

One thing that always bugged me, was Osmorc’s somewhat convoluted settings dialog. Usually in IntellIJ you have project settings and application settings in two areas of the settings dialog. Osmorc however always had both things mixed in the project settings area. This will change in 1.2.2, and things will go where they belong.

Additionally the whole thing has been refactored a lot internally so the settings dialog now opens 1 second faster (at least on my machine). And we all do like a faster settings dialog in IntelliJ, don’t we?

I’ve recently been going over the feature wishlist for Osmorc and I found quite some items regarding support for a “Manifest First” style of developing applications. From my experience it becomes increasingly difficult and complex to maintain a growing set of OSGi manifests in bigger projects by hand. And with tools such as BND or Bundlor available, I have a hard time in understanding why anyone would want to manually manage manifests.

Then again, these feature requests exist and they exist for a reason. To shed some light on these reasons I decided to put up a small survey about “Manifest First” vs. “Code First” and just ask for your feedback. It’s only four questions and it would really help me a lot in deciding which path to go with Osmorc in the future and spend the limited development time on the most important features.

So please take the survey and help improving Osmorc!

A new version of Osmorc has been released to the plugin repository. The changelog for this new version is:

Features

• You can now set up a default start level which will be used for starting your dependencies.
• The run configuration dialog now has some spinners for selecting the start level.
• You can now specify program parameters for pax runner in the run configuration.

Bugfixes

• Osmorc will no longer create facets for Maven projects which are not of type “bundle”.
• The facet importer will no longer use bundlor template manifests (template.mf) as source, but rather work on the generated manifests.
• Exploded bundles are now correctly started up.
• The bundle compiler will now issue a more usable message when a manifest file is missing.
• A few issues with the bnd wrapper have been resolved.
• Various reported exceptions have been fixed.

As usual your feedback on this version is most welcome. Should you find any bugs or have ideas for new features, please add them to our issue tracker.