With version 1.2.2 SpringSource’s Bundlor manifest generating tool is now supported by Osmorc. In the facet settings there is a new option to use a Bundlor manifest template to generate the manifest for a module. The facet importer will also detect template.mf files in your project and set up the OSGi facet to use Bundlor in this case.![]()
What’s currently not implemented is auto-bundling libraries with Bundlor (this is still done exlusively with bnd) and an import from the Bundlor maven plugin. These will be added in a future version.
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.
Since the release of IntelliJ Community edition, many newcomers have taken a spin on IntelliJ. It is common that things like how to install plugins are not easily apparent to people who switch from other IDEs so I decided to make a small video showing how you can install Osmorc in IntelliJ IDEA Community edition.
A big thanks goes over to the guys at Vimeo who make creating and publishing videos a straightforward and easy thing.
The other day i noticed that the move from the old server has broken quite a few things in here, most notably the comments function. I therefore decided to do some upgrading to Movable Type 5 and fixing a few missing redirects in the server configuration so things are now back in working state.
The first version of Osmorcs 1.2 version series is to be part of IntelliJ 9.0.2 Ultimate Edition, which is scheduled to be released soon. Users of the community edition will be able to download it through the plugin repository (though buying IDEA Ultimate is of course strongly encouraged ;).
This release contains the integration with PAX Runner, that took a really long time to implement. This integration vastly improves Osmorcs reliability when it comes to starting OSGi containers. Also a much wider range of versions of all four major OSGi containers is now supported. The version of PAX Runner that is part of Osmorc has been slightly modified, so it can also launch Eclipse RCP based applications in Equinox. Even though PAX Runner launches it’s own VM with the OSGi container, you don’t need to resort to remote debugging but you can actually just press the “Debug” button in IntelliJ to debug your bundles.
1.2.0 is a major improvement of Osmorc and I am very excited and happy about it. I hope you like it as well. Feel free to leave comments here on the blog and send in feature requests and bug reports at our issue tracker!
Version 1.1.1 of the plugin has been released to the plugin repository yesterday. It is also part of the next EAP of IntellIJ IDEA. This release is a bugfixing release which fixes a lot of annoying and partially showstopping bugs in 1.1.0.
Meanwhile work on 1.2 has continued. Pax integration is running solid for all four frameworks, debugging is working as well. Support for RCP applications is currently being added. This will provide a solid foundation for running OSGi frameworks in the future. Once this foundation is in and working, work will continue on the other items that have been mentioned in the previous post.
In the last few weeks work on Osmorc has been a bit slow due to team changes, the holidays and a few personal things I had to attend to. However, development has come up to speed again so I’d like to bring up a few of the things I am working at to your attention.
- Pax Runner: There were many requests on the issue tracker and the plugin page to support Pax Runner. Current integration looks promising, the basic things like starting up a framework and deploying some bundles work very well. More advanced stuff like Eclipse applications and debugging is still in the works.
- UI Changes: The UI will be further streamlined. The run configuration dialog has become somewhat bloated and looks a bit different for each OSGi service - this will change. I am also looking at splitting up IDE and Project configuration so Osmorc behaves like all other plugins in that regard.
- Interaction with the running OSGi framework: Currently we only provide a console for Equinox and nothing for other OSGi frameworks. First step will be providing a console for all frameworks. A second step could be some graphical interaction (something like the GUI that Knopflerfish provides).
- Documentation: OSGi is a complex matter and Osmorc usage isn’t as straightforward as it could be. The documentation is somewhat outdated as well. A few tutorial videos could help as well.
So far these are the things being currently under work. The blog will hopefully see a few more entries than pure release announcements in 2010 as well. So stay tuned in . If you work with Osmorc and require a feature, please feel free to submit an issue to the issue tracker.
