Results tagged “release” from Osmorc

Osmorc 1.1.0 is actually the second release of Osmorc for IDEA Community Edition. The first one was released last week. We didn’t announce it then, but now it’s official. Osmorc is now also available for the community edition and to celebrate this we also release a preview of a new user’s guide for Osmorc.

We are aware that Osmorc needs documentation. We keep being asked the same question over and over again. So we take a new try at the task of providing documentation. This time it’s a book - a user’s guide -. It’s far from finished. Currently it’s only available as PDF and only in the A4 format, but we’ll provide other formats in the future and maybe we’ll generate JavaHelp and other formats from it.

The plugin is available through IDEA’s plugin manager and the user’s guide can be downloaded from our SourceForge project page. The user’s guide may also be of interest to users of IDEA Ultimate which bundles the plugin.

Yesterday we released version 0.14.0 for IDEA 8. This release contains nearly all of the features and bugfixes we’ve done for the bundled IDEA 9 version we’ve been developing since early May.

Here’s the changelog:

• Merged Equinox Run config into OSGi Bundles run config.
• QuickFix that registers a Bundle Activator in the manifest file or Osmorc facet configuration.
• Osmorc facet detection now only requires that a manifest file contains a Bundle-SymbolicName.
• Osmorc now makes sure that a manifest file is not readonly before trying to change it.
• Bundle compiler has been rewritten and now supports bnd files much better.
• Facet configuration dialog has received a rework to make it more intuitive to use.
• Lots of smaller bugfixes.

This will most likely be the last Osmorc release for IDEA 8.

This release fixes some bugs (see this version in Jira) and brings the following notable changes and features:

• Added autocompletion for known manifest header names.
• Equinox 3.4 source bundles are now used correctly.
• Reworked additional JAR contents section in facet configuration. Source files and directories are now selected via a file chooser and a destination name that will most times be correct is inferred.
• Splitted the facet editor into smaller parts.
• Changes to files belonging to the additional JAR contents of a bundle now trigger a rebuild of the JAR.
• Added specific Equinox, Bnd and Spring DM headers to the headers known by Osmorc.

Note that you’ll have to edit each entry in the additional JAR contents since the paths are now stored differently. In most cases selecting an entry, clicking “Edit” and confirming the default choices will suffice.

This end of year release has some new features for running Equinox products and applications and fixes a critical bug in the OSGi Bundles run configuration.

The critical bug prevented the usage of the OSGi Bundles run configuration in most cases. So anyone using or trying to use it should update.

For the Equinox run configuration type the following features were added:

• additional JVM parameters can specified.
• additional Equinox parameters can be specified.
• the runtime directory can be specified
• products and applications based on Eclipse 3.1 and 3.2 can be run

A regular expression can be specified to filter out files from the additional JAR contents.

Thanks for contributions for this release to Nick Pratt.

0.10.0 comes with the following changes and new features:

• OSGi bundles run configuration: bundles which are part of the framework can now be started.
• OSGi bundles run configuration: libraries which are themselves OSGi bundles can now be started.
• Multiple rules can now be applied when building a library bundle.
• Bundle version from facet dialog is now correctly built into the manifest.
• Library cache can now be deleted with a button in library building dialog.
• Fragment bundles are now handled correctly when manifest files are edited manually.
• The classpath used by the run configurations to start the OSGi container now only contains what is needed to start the container.
• Added spell checking for manifest header names.

This release brings the integration of one more framework type: Concierge OSGi (thanks to Alain Greppin) for the initial code),

Note: The Concierge and Felix framework types cannot be used as the base for projects which use manually edited manifest files if the modules of such a project import any of the core OSGi classes - such as BundleActivator.Neither of those two framework types exports those packages and so, dependencies won’t be created to the bundles containing those classes. The end result is then that your BundleActivator won’t be compileable. You can use them as framework instances for launching bundles in the generic “OSGi Bundles” run configuration, though.

The generic “OSGi Bundles” run configuration type got some enhancements. Start levels for the selected bundles can be set and it’s also possible to specify boot delegation and system packages for Felix and Knopflerfish framework instances.

The “Eclipse Equinox” run configurations now check whether there is an Equinox framework instance selected for the project and puts out helpful error messages if that is not the case.

For people letting Osmorc generate the manifest files via bnd there is a new configuration page where rules for the creation of bundles from libraries can be specified.

As always some bugs were also fixed.

Currently Osmorc’s ErrorHandler is deactivated. So you won’t be able to click the “Blame Osmorc” button. The ErrorHandler causes some strange errors on Mac OSX which we are currently investigating. Please post your bug reports manually on Osmorc’s JIRA for the time being.

This release has only one major change: Osmorc now runs on IDEA 8.

Porting Osmorc to IDEA 8 wasn’t as much of a pain as I originally thought. So only 5 days after the 0.7.0 release here’s Osmorc for all those waiting to run it on IDEA 8.

A note to those using 0.7.0: There is one inconvenience in the 0.7.0 release that is fixed in 0.8.0. With 0.7.0 you have to rebuild your modules manually after a change before starting an Equinox run configuration. With 0.8.0 the rebuild of changed modules and with that the rebuild of the bundle JAR files is triggered by the run configuration.

Here’s another Osmorc release.

The biggest new feature is running of Eclipse Equinox applications and products. We have a new run configuration type named “Eclipse Equinox” that will allow you to specify a product or an application to run. It’s still kind of basic, though. You cannot specify which bundles to install. We currently install all bundles of a project.

There’s still no handling of additional library jars, but if your bundles don’t use any libraries that are not available as bundles, it should work. You will need to specify the Eclipse plugin.xml as additional JAR contents in the facet settings to make it work. The documentation contains more information about that.

Defining additional JAR contents may also be useful to people not using Equinox. Take a look at the facet settings and the documentation available through IDEA’s help system.

With this release Osmorc can also handle modules with more than one content root. Osmorc scans all content roots of a module when it searches for manifest files or files defined as additional JAR contents and takes the first matching file.

The bundle dependency resolver that is used when Osmorc generates the manifest files has also been improved. More work will be done on this areas — as on any other — in future releases.

This release will most likely be the last release for IDEA 7. The next one — 0.8.0 — will be the first release for IDEA 8.

Today I released version 0.5.0.

It is mainly a maintenance release fixing some nasty bugs reported by users.

I also added some more documentation that should give anyone new to Osmorc an idea how Osmorc works and how to get started with it. The documentation is far from finished and I will add to it with each new release. It’s probably typical but I just cannot spend two weeks or something like that with only writing documentation. It would kill me - sort of.

Please take a look at this version in JIRA for a list of fixed issues.

Finally after two months of development I’m pleased to release the next update of Osmorc.

The big new feature of this release are framework instances (a.k.a “target platform” in Eclipse). For the creation of framework instances three OSGI implementations are supported out of the box: Eclipse Equinox, Knopflerfish and Apache Felix. The framework integrators for those implementations take care of collecting all bundles and their sources from an installation folder. Please read the also newly added documentation which is available through IDEA’s help system to learn about specific constraints for the different implementations.

One known issue is that when you add a framework instance (See File | Settings | Project Settings | Osmorc) and directly choose it for the current project, the dependencies on the then newly generated global libraries are created and can be seen on the “Module dependencies” page, but they don’t appear below the Libraries node of the modules in the project view. A work around for this is to first define the framework instance, apply the settings and then reopen Osmorc’s settings dialog and choose the framework instance for the project or to simply close and reopen the project.

Also new is the autodetection of the Osmorc facet when an existing manifest file contains the Bundle-ManifestVersion and Bundle-SymbolicName headers. On the other side when an Osmorc facet is added to a module without a manifest file a manifest file is generated for it.

The road map has changed a bit. Adding run configurations has been pushed to version 0.6.0. In version 0.5.0 I will try to fix an inconvenience concerning framework instances. Since global libraries are created for the bundles of a framework instance and dependencies from modules to those libraries are added when the corresponding bundle is required or one of its packages is imported, there’s no easy way to see which bundles are available in the chosen framework instance. A solution I will investigate for 0.5.0 is to create wrapper modules for the global libraries of the framework instance used in a project.

This release of Osmorc integrates Eclipse Equinox which is used to resolve bundle dependencies. Now versions and other constraints are taken care of. Thanks to Gerd Wütherich for pointing out to me that Equinox can be used outside a running OSGI system for this purpose.

With this integration the further roadmap changes a bit. Before I was working hard to get the whole manifest parsed. While this is still an important feature to me, it isn’t top priority anymore. The next task on the list is to get definition of a target platform working. As soon as that is achieved, Osmorc will start to be really useful for real-life projects.

Afterwards I will return to parsing of manifests and will provide more cross-referencing and more error recognition and quick fixes.

Note: Integrating Equinox doesn’t imply canceling support for other OSGI implementations. The support for specific implementations will become apparent the first time with the added ability to define a target platform.

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.

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.