Today I released version 2.2.0 of the maven-bundle-plugin from Apache Felix. This release may look like a minor update because it only contains two fixes, but one of them is very important. The workhorse behind the maven-bundle-plugin, Peter Kriens’ bnd tool, has been upgraded from 0.0.384 to 1.15.0. The new version is much smarter in deciding which packages to export and import, and supports easy creation of Web Archive Bundles (WABs) which can act both as bundles and standard WAR files. Add numerous other small improvements and fixes to the mix and this should result in a much better experience overall.

Special mention should be made of the efforts of Juven Xu and Peter Kriens who worked together to add Nexus OSS staging to Peter’s Ant build. Previously bnd artifacts were manually uploaded by occasional third-party requests to MAVENUPLOAD, often a very laborious process. Third-party uploads to Maven Central have since been streamlined and automated with Nexus, but OSS hosting is still preferred by project owners who want to stage and check artifacts as part of their regular build process.

On behalf of all the OSGi developers who use the maven-bundle-plugin I’d like to thank Juven and Peter for their work getting the latest versions of bnd onto Maven Central!

Holger Staudacher, at EclipseSource, has a good writeup of his experience evaluating Tycho for the Runtime Packaging Project (RTP). Here’s an excerpt of what he has to say:

Recently I played around a little with Tycho because we evaluated it for the use in the RTP project. As a test case, I decided to try to build a RAP application with Tycho. With building I mean compiling and packaging the artifacts into a WAR file in order to deploy them on a Tomcat or another Servlet Container. I have to say that I’m really impressed with Tycho. Before this experience…

It’s great to see different projects trying Tycho at the Eclipse Foundation: having standard recipes for building RAP applications would be extremely useful addition for the community. RAP is not something that Sonatype is directly involved with so it’s great to get this varied perspective, and different applications types so we can make sure Tycho will work for as many use cases as possible. Thanks Holger!

Holger has some good examples at Github, and you can find his original blog entry here.

We are currently working on submitting the CQs for Tycho so we can move the project over to the Eclipse Foundation. I think Wayne Beaton said he wanted to help with those CQs. Right Wayne?

For those you following along with our story on improving Maven, you’ll happy to know that we have made a significant step today with the release of Maven 3.0-alpha-3. Though we are marking this as an alpha release, we are largely feature complete for Maven 3.0 and consider this to be the best version of Maven that has ever existed.

Our primary goals with Maven 3.0 are:

1) Provide a drop-in replacement for Maven 2.x. You should not have to change your POMs, or rewrite plugins. Your projects should just work.

2) Provide a more reliable, stable and performant Maven. We have tried to make Maven 3.x faster and we’ve succeeded for any of the projects that we’ve tested. We have a performance framework in place to make sure we don’t regress. We are measuring network I/O, disk I/O, CPU utilization and memory usage. We also have a massive number of integration tests to make sure the behaviour remains consistent and compatible as we progress. We simply aren’t going to go backward at this point.

3) Synchronize the M2Eclipse releases with Maven 3.x so that we can immediately push fixes from Maven 3.x into M2Eclipse. For a long time M2Eclipse was out of sync with Maven trunk and created a great number of problems. We are now completely in sync and within hours of making changes in Maven 3.x they make it into the CI builds of M2Eclipse.

4) Provide an easy way to embed Maven as a library. I think we’ve really proven this with M2Eclipse but Sonatype has two other efforts taking place. The first is to embed Maven 3.0 into Hudson and the second is to embed Maven 3.0 into Nexus. The APIs that we are creating not being final is largely why we are still releasing alphas. From a CLI perspective we’re pretty much done, from an embedding perspective we still have some work to do.

4) Provide a solid base for extensions and reuse. There are three efforts going on here which are pushing the boundaries of Maven 3.x:

• Tycho: Which is Sonatype’s toolchain for building OSGi bundles and Eclipse plugins & RCP applications. The changes that we made in Maven 3.x to accommodate the embedding of an OSGi runtime (in our case Equinox) was non-trivial. We’ve been working on this for over a year and we have what we believe to be the best hybridization of Maven and OSGi technologies. Maven was stretched, and pushed and pulled to get all of this to work. I believe the current adoption of Tycho by the Tigerstripe at Eclipse.org is a sign of things to come. Users want to build OSGi bundles and Eclipse plugins using real OSGi technologies with Maven and we have delivered.

• Polyglot Maven: This is our attempt to create a great degree of flexibility in the core of Maven 3.x. We provide the ability to easily pull POM information from any data source and allow DSLs access to core functionality in Maven to create new tools using Maven 3.x. The development of Polyglot Maven has sparked a lot of interest and we hope to make public release in the next month.

• Maven Shell: An attempt to provide an embedded form of Maven for typical CLI users. We are planning to

  • Provide more intelligent caching implementation to make builds faster. Already we are seeing 100-200% speed increases over using the standard CLI (which itself is already faster then Maven 2.x).
  • Integrate a powerful form of the Make-like reactor that is built into Maven 3.x to make working in the shell extremely efficient.
  • Integrate an advanced form of Archetype so that we can provide a power scaffolding framework for general application development.

We are not forgetting about documentation either. All the work that has been done in Maven 3.x is currently being documented in Maven: The Definitive Guide and we will be complete when Maven 3.0 goes GA. We also have some pretty cool site generation tools that I am using to create a new Maven 3.0 site which is also be ready in time for the final release.

For now, Benjamin and I are preparing for any feedback from users who want to try the alpha-3 release and we’ll be standing by to apply patches and make fixes for anything that users find — just like we have for the last year. This is part of Sonatype’s ongoing committment to help sustain the Maven ecosystem to provide the support, tooling, and documentation to help get new users and developers involved.

You can download the Maven 3.0-alpha-3 here:

• http://www.apache.org/dyn/closer.cgi/maven/binaries/apache-maven-3.0-alpha-3-bin.zip
• http://www.apache.org/dyn/closer.cgi/maven/binaries/apache-maven-3.0-alpha-3-bin.tar.gz
• http://www.apache.org/dyn/closer.cgi/maven/binaries/apache-maven-3.0-alpha-3-bin.tar.bz2

Enjoy!

We’ve released a pre-alpha version of the Maven Cookbook which contains a chapter on OSGi development with Maven via the Pax plugin from OPS4J. This chapter contains a series of recipes which will walk you through the process of creating an OSGi project, importing bundles from both a Maven repository and existing OSGi Bundle Repositories (OBR), and executing an OSGi runtime environment all with the help of the Maven Pax Plugin. The last few chapters provide a road map for developers interested in hosting and combining multiple Maven and OBR repositories into a single repository group with Nexus.

To read the pre-alpha, version 0.1.1 release of the Maven Cookbook, you can:

• Read the Maven Cookbook on Scribd
• Read the Cookbook Online
• Download a PDF of the Maven Cookbook

Over the last month or so I have been working on adding OSGi Bundle Repository (OBR) support to Nexus Professional, and I am happy to announce this feature will be available in the 1.3.5 release. But what exactly is OBR and why should you care?

OBR has been around since 2006, it defines a small XML schema and Java API that allows clients to discover and deploy OSGi bundles by matching capabilities with requirements. Distributors provide XML describing their bundles, and this is used by OBR service implementations running on OSGi frameworks. Management clients talk to their local OBR service using the Java API.

Example

Here’s a concrete example, the Apache Felix project has XML describing their bundle releases:

http://felix.apache.org/obr/releases.xml

They also provide an OBR service implementation that works on any R4 OSGi framework:

<dependency>
  <groupId>org.apache.felix</groupId>
  <artifactId>org.apache.felix.bundlerepository</artifactId>
  <version>1.4.0</version>
</dependency>

Let’s see OBR in action!

1. Go to http://felix.apache.org/site/downloads.cgi and download the 1.8.0 distribution
2. Extract Felix 1.8.0 to a local temporary directory
3. cd felix-1.8.0
4. java -jar bin/felix.jar

You should see the Felix command shell, type obr to see the available OBR commands:

 Welcome to Felix.
 =================
 -> obr
 obr help [add-url | remove-url | list-url | list | info | deploy | start | source | javadoc]
 obr add-url [<repository-file-url> ...]
 obr refresh-url [<repository-file-url> ...]
 obr remove-url [<repository-file-url> ...]
 obr list-url
 obr list [-v] [<string> ...]
 obr info <bundle-name>|<bundle-symbolic-name>|<bundle-id>[;<version>] ...
 obr deploy <bundle-name>|<bundle-symbolic-name>|<bundle-id>[;<version>] ...
 obr start <bundle-name>|<bundle-symbolic-name>|<bundle-id>[;<version>] ...
 obr source [-x] <local-dir> <bundle-name>[;<version>] ...
 obr javadoc [-x] <local-dir> <bundle-name>[;<version>] ...

This service is pre-configured to use the Felix OBR, to see a list of released bundles type:

 -> obr list
 Apache Felix Bundle Repository (1.2.1, ...)
 Apache Felix Configuration Admin Service (1.0.4, ...)
 Apache Felix Declarative Services (1.0.8, ...)
 Apache Felix EventAdmin (1.0.0)
 Apache Felix File Install (1.2.0, ...)
 Apache Felix HTTP Service Jetty (1.0.1, ...)
 Apache Felix iPOJO (1.2.0, ...)
 Apache Felix iPOJO (0.8.0)
 Apache Felix iPOJO Arch Command (1.2.0, ...)
 Apache Felix iPOJO Composite (1.2.0)
 Apache Felix iPOJO Composite (1.0.0, ...)
 Apache Felix iPOJO Event Admin Handler (1.2.0, ...)
 Apache Felix iPOJO Extender Pattern Handler (1.2.0)
 Apache Felix iPOJO Extender Pattern Handler (1.0.0, ...)
 Apache Felix iPOJO JMX Handler (1.2.0, ...)
 Apache Felix iPOJO Temporal Service Dependency Handler (1.2.0, ...)
 Apache Felix iPOJO White Board Pattern Handler (1.2.0, ...)
 Apache Felix Log Service (1.0.0)
 Apache Felix Metatype Service (1.0.2, ...)
 Apache Felix Prefrences Service (1.0.2)
 Apache Felix Remote Shell (1.0.2)
 Apache Felix Shell Service (1.0.2, ...)
 Apache Felix Shell TUI (1.0.2, ...)
 Apache Felix UPnP Base Driver (0.8.0)
 Apache Felix UPnP Extra (0.4.0)
 Apache Felix UPnP Tester (0.4.0)
 Apache Felix Web Management Console (1.2.10, ...)
 OSGi OBR Service API (1.0.0)
 OSGi R4 Compendium Bundle (4.0.0)
 Servlet 2.1 API (1.0.0)
 ->

Say we’re interested in the Felix Web Management Console, to deploy and start this bundle type:

 -> obr start 'Apache Felix Web Management Console'
 Target resource(s):
 ------------------–
    Apache Felix Web Management Console (1.2.10)
 Required resource(s):
 --------------------–
    Apache Felix HTTP Service Jetty (1.0.1)
    OSGi R4 Compendium Bundle (4.0.0)
    Apache Felix Log Service (1.0.0)
    Apache Felix Declarative Services (1.0.8)
 Deploying...org.mortbay.log:Logging to org.mortbay.log via org.apache.felix.http.jetty.LogServiceLog
 org.mortbay.log:Init SecureRandom.
 done.
 ->

Notice the OBR service was able to deduce we needed other bundles to successfully run the Web Management Console, and it automatically deployed and started them as well. To prove that the Web Console is now up and running, go to http://localhost:8080/system/console/ and log on using admin as both the user-id and password.

Nexus Pro

That should have given you a taste of OBR, but how does this relate to Nexus Professional?

Well with Nexus Pro 1.3.5 you will be able to:

1. dynamically generate OBR metadata for your existing repositories
2. proxy and cache remote OBRs, including both metadata and bundles
3. host local OBRs and deploy bundles into them using the UI or Maven
4. group all of the above types of OBRs into a single merged OBR
5. apply CRUD privileges to control access to particular bundles

Basically the same things you can do with Maven and P2 repositories you can now do with OBR!

This screencast shows how you can quickly build up and use OBR metadata using Nexus Professional 1.3.5. We have also been able to reconstruct the OSGi Alliance repository in a matter of minutes by proxying known public sites and grouping them into a single OBR.

Future

What does the future hold for OBR? Well although it’s existed as a draft specification since 2006, it has not yet been formally standardized by the OSGi Alliance. Since then alternative approaches have appeared, such as P2. The OSGi Alliance have therefore decided to revisit the original requirements and see where OBR can be improved, given what we know now about deploying large applications in OSGi.

So the final OBR specification might vary from the current draft, but if you use Nexus Professional to manage and generate your OBR metadata this shouldn’t bother you. The repository abstraction in Nexus makes it very easy to add support for new metadata formats, which means we will be able to support both the old and new formats as required.

At Sonatype we’re starting to release some of the P2 related support we’re developing. The release of Nexus 1.3.2 has the basis for all our future P2 work. We see Nexus Pro helping OSGi users to provision their systems whether that be a developer desktops or server side instances. We will be making provisions (pun intended) to support some very sophisticate server side provisioning, but in the Nexus 1.3.2 release we are focusing squarely on helping organizations manage their Eclipse installations for their developers.

Nexus Professional has support for Eclipse P2 repositories, and it can serve Eclipse plugin artifacts to tools that know how to interact with the Eclipse P2 repository format including Eclipse 3.4 Ganymede. If you use the Eclipse IDE, you probably have a set of plugins which every single developer needs to install to get productive. Using Nexus Professional, you can combine multiple Eclipse update sites into a single URL which your developers can use when they are configuring a development environment. Using Nexus Professional as a single point-of-access between your developers and the Eclipse update sites they depend on allows you to manage and define a set of common Eclipse plugins in your organization’s Eclipse development environment.

You can now easily manage all your 3rd party artifacts whether they be JARs, OSGi bundles, or Eclipse plugins. Not only managing how these artifacts are consumed, but how they are exposed within your organization, tracking how they were acquired, and helping produce the necessary bill of materials at the end of the development cycle. We’re pretty excited about the features we’re developing in Nexus!

You can watch a screencast of our P2 support here:

Provisioning Eclipse with Nexus Pro from Sonatype on Vimeo.