maven-bundle-plugin 2.0.0 released!

The Apache Felix team is pleased to announce the release of maven-bundle-plugin 2.0.0

This release uses the latest bndlib (0.0.311) which requires you to build with a Java5 JDK. You can continue to target earlier JVMs while building with a Java5 or later JDK by setting the source and target levels in the maven-compiler-plugin configuration.

Here is the list of issues fixed in this release:

Bug

• [FELIX-545] - Export-Package version inconsistencies.
• [FELIX-546] - Import-Package version inconsistencies.
• [FELIX-549] - Import-Package should not include "snapshot" from snapshot dependencies
• [FELIX-660] - "Class in different directory than declared" error when bundle classes in a directory other than bundle root
• [FELIX-677] - Parser throws error when DynamicImport-Package contains attributes
• [FELIX-699] - manifest goal does not interprete _include instruction correctly
• [FELIX-782] - Manifest goal ignores version attribute specified in _exportcontents
• [FELIX-807] - conversion of JAR into bundle fails if there are classes is the default name space
• [FELIX-831] - bndlib unnecessary modifies valid OSGi Bundle-Version numbers (update to bndlib 0.0.293)
• [FELIX-843] - Regression: BND 0.0.295 does not augment Ignore-Package with excluded import packages
• [FELIX-850] - Wrong symbolic name computed when groupId is a single segment string.
• [FELIX-864] - A wrong symbolic name is calculated if artifactId starts with lastGroupIdSegment-.
• [FELIX-899] - Version attribute missing from Import-Package on provided dependencies
• [FELIX-907] - Regression in latest BND code: negated exports are applied to private packages

Improvement

• [FELIX-684] - Enable excludeDependencies to check groupId, version, etc. rather than only artifactId
• [FELIX-806] - changing the internal configuration of the archive plugin doesn't seem to be possible
• [FELIX-941] - Support singleton & fragment-attachment directive generation

New Feature

• [FELIX-912] - Improve default Export-Package / Private-Package settings by scanning the project source

A quick bundle example using the classic Maven quickstart project:

  mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app

# edit the pom.xml, change packaging from jar to bundle and add:

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.felix</groupId>
        <artifactId>maven-bundle-plugin</artifactId>
        <version>2.0.0</version>
        <extensions>true</extensions>
      </plugin>
    </plugins>
  </build>

  mvn clean install # you should now have a valid OSGi bundle

plugin docs: http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
plugin FAQ: http://felix.apache.org/site/apache-felix-bundle-plugin-faq.html
bnd docs: http://www.aqute.biz/Code/Bnd

--
Regards, the Apache Felix team

maven-bundle-plugin 2.0.0 coming soon

Just started a vote for the next major release of the maven-bundle-plugin, if all goes well it will be published to Maven central next Wednesday (4th March).

Guice feature comparison

Yesterday Jesse added this table to the Optional AOP page of the Guice wiki:

	Guice 1.0	Guice 2.0	Guice+AOP 2.0	GIN
Library size	544Kb	420Kb	640Kb	0Kb (code gen)
High performance	✔	✔	✔	✔
Binding EDSL	✔	✔	✔	✔
Scopes	✔	✔	✔	✔
Typesafe	✔	✔	✔	✔
Fast reflection	✔ (cglib)		✔ (cglib)	✔ (code gen)
Line numbers in error messages	✔		✔
Method interceptors	✔		✔
Provider Methods		✔	✔	✔
Binding overrides		✔	✔
Tool-friendly SPI		✔	✔
Child Injectors		✔	✔
Servlet Support	Scopes Only	✔	✔
Error Reporting	Good	Better	Best	Best

I think it's a great summary and shows how flexible the new release will be.

Guice-Peaberry vs Spring-DM

six times as fast, half the size!

Of course it's never that simple, these are just some fun measurements I took today using a trivial testcase that injects an OSGi service. They completely ignore functionality, flexibility, usability, and many other *bilities... flame-on!

Happy new year!

Just completed one of my new year resolutions and uploaded a release candidate of peaberry. See my message on the Guice-OSGi group for a few more details.

OK onto my next resolution, back to writing more chapters for OSGi in Action...

Want to hear the latest on Guice and OSGi?

Then you'll want to attend EclipseCon 2009, where you can hear me talk about using Guice and the peaberry extension to blend OSGi services with Eclipse extensions:

http://www.eclipsecon.org/2009/sessions?id=315

I'll also be running through some of the design decisions behind peaberry which I think are pretty neat - like the recent work on "outjection" that lets you share services between registries and watch for service updates. If I have time I'll also discuss some thoughts about lifecycle support (for some background see Todor's recent request).

I'm going to be around for the whole conference, so you'll have plenty of opportunities to ask me questions about peaberry, Pax-Construct, the maven-bundle-plugin, or the "OSGi in Action" book :)

How much OSGi should I use?

This began as a quick reply to a question on the Felix users list about bundling third-party libraries, but these days once I start writing I find it hard to stop! Hope you find it useful...

It's actually up to you - OSGi doesn't force you to make everything a bundle, it merely helps you when you decide to modularize.

So if you want to put third-party libraries on your application classpath and use the "org.osgi.framework.bootdelegation" property to make them visible to all bundles then you can. You could then concentrate on modularizing your application without worrying about legacy classloading issues - however it would also mean you couldn't replace these libraries at runtime, or have multiple versions of them loaded at the same time. Additionally, if you use tools to generate OSGi manifests you'd need to tell them that these packages should not be marked as imported, as they're available instead using bootdelegation - otherwise your bundles would have trouble resolving, because no other bundle would be exporting these packages.

Or you could keep the libraries on your application classpath and use "org.osgi.framework.system.packages.extra" to augment the exports from the main system bundle. Unlike bootdelegation, your bundles would need to import any of these packages they want to use - and these imports would then get wired to the system bundle. However, because you're now using OSGi resolution to find these packages you could replace them at runtime and have other bundles provide alternative versions. The downside is that you may find issues with a few legacy libraries that expect the "classic" model (ie. everything on the application classpath)

Later on you might decide to move libraries from the application classpath into one or more OSGi bundles - you could either crack open the library and add OSGi metadata to the manifest to export everything, or use a tool like BND to create a new jar based on the original. This is great if you want to share libraries between bundles - but if the library is only used by one bundle then it might make more sense to embed the library inside that bundle, especially if it's an implementation detail and you never expect to export any packages. Again you have a choice: you can unpack the library inside your bundle, or embed the jar as-is and add it to your Bundle-ClassPath (OSGi supports "jars within jars").

Once you have the third-party library as (or inside) an OSGi bundle then you can start thinking about making certain packages private, and add a Bundle-Activator to initialize and clean up resources and/or threads. Using an activator is optional and while it will introduce a compile time dependency to OSGi, it doesn't force the library to use OSGi at runtime. You can still use the library in classic Java applications, because they won't attempt to load the activator class. This is cool, because it means you can fully participate in the OSGi lifecycle without affecting anyone not interested in OSGi.

The best part is that you can mix any of these approaches in your application and you can decide when move between them. You're not forced to make everything a bundle, and you may even decide to move bundles back to the application classpath. Feel free to use as much or as little of OSGi as you like :)

Cat massage, courtesy of Friesia