Ben Hale

I’m very excited to announce that Bundlor 1.0.0.RC1 is now available. There have been numerous changes to Bundlor since the M6 release including additions to detection and warning criteria as well as improvements to the ANT and Maven configurations.

This milestone marks feature-complete status for the 1.0.0 release. Baring any major issues, this candidate will be released as 1.0.0.RELEASE shortly.

Detection and Warning Criteria

Bundlor now detects Java types in the following locations:

• Java Types


• Spring Context Files


• Blueprint Service Configuration Files


• Web Application Files


• Contained JARs


• JPA Configuration Files


• Hibernate Configuration Files


• JSP Files


• Log4J Configuration Files


• Static Resources

dm Server 2.0.0.M6 is now available and can be downloaded from here.

This release follows quickly on the M5 release as we close in on the first 2.0.0 release candidate. This time we’ve focused very heavily on fixing outstanding defects and added just a handful of new features. Take a look at the M6 release notes for the full details of the defects that we’ve fixed and the features we’ve added. Please keep your feedback coming as comments on our blog, in the forums, and on the JIRA.

New and Noteworthy

dm Server 2.0.0.M5 is now available and can be downloaded from here.

We’re getting towards the end of the 2.0.0 release cycle so most of the work in this milestone is focused on locking down the user interaction model. Take a look at the M5 release notes for the full details of what we’ve been working on. Please keep your feedback coming as comments on our blog, in the forums and on JIRA.

Please also watch the blog for detailed posts on many of the new features referenced in this New and Noteworthy.

I’m pleased to announce that beginning with its newly released 1.0.0.M6 version, Bundlor now supports OSGi Blueprint Service files.

As with the support for Spring-DM contexts, Bundlor scans for Blueprint Service configuration files in both the default location (OSGI-INF/blueprint/*.xml) and in locations specified with the custom Bundle-Blueprint manifest header. When these files are found, they are scanned for class and interface names and the packages for those types are added to the OSGi manifest that Bundlor creates.

I’m pleased to announce a new screencast for SpringSource Slices. This screencast walks through the creation of the menu-bar sample application. It shows how a host can use a collection of slices to populate a menu bar dynamically without restarting and can be completely de-coupled from the knowledge of exactly what items might be in the menu-bar. In addition, the slices only provide their specific content, and include formatting and other window content from the host bundle.

Slice Menu Bar (5:19)

Some of you may have noticed that in recent posts that the dm Server team has been referencing Git repository URLs. The team has been migrating all of its source code and I’m now pleased to announce that this migration is done. The list below contains the Git URLs for the code managed by the dm Server team. If you were referencing the equivalent repositories in SVN, please clone these new repos instead.

This announcement only covers code managed by the dm Server team, and not the entirety of the Spring portfolio. Other projects will be converting at their own pace and the Subversion repositories will stay open until they do.

Shortly after the introduction of SpringSource dm Server (Application Platform at the time), Thorsten Maus created a Maven plugin for creating PAR files. This was a great community contribution and we even used it in the Getting Started Guide for dm Server 1.0.x.

As dm Server’s 2.0 milestones have progressed we’ve been adding new functionality to the PAR file. The most interesting feature is that now a PAR file can contain more than just JAR files. With the introduction of OSGi RFC 66, the dm Server has deprecated Web Modules in favor of the standard Web Container files using a .war extension.  Because of this, the PAR plugin needed to be updated to support these different types as dependencies.  Thorsten graciously agreed to donate his code to SpringSource and I’m pleased to announce the 1.0.0.M1 release of the Apache Licensed Maven PAR Plugin.

I’m pleased to announce the 1.0.0.M1 release of SpringSource’s OSGi Test Stubs.  These stubs offer a way to unit test complex OSGi Framework interactions without needing a full OSGi container.

• Package - Download


• Git - git://git.springsource.org/osgi-test-stubs/osgi-test-stubs.git

The Problem

As the dm Server team has been developing, we found that one of the biggest problem areas for testing for us was in BundleActivators.  Our BundleActivators do quite a bit of publishing services to the service registry as well as consuming services using ServiceTrackers.  These kinds of tasks involve many interwoven calls to BundleContexts, Bundles, ServiceRegistrations, and ServiceReferences.  In the beginning, these activators were simple enough that not much unit testing was done on them, and we depended on integration tests to catch any bugs that were introduced.  As time went on though, the activators became more complex and unit testing became a more pressing need.  We started using EasyMock for these tests, but found that they were very complex, hard to maintain, and most importantly hard to understand.

In the dm Server 2.0.0.M1 release we added support for shared repositories. As a followup to this new functionality, we’ve added support for browsing those repositories via JMX.

Connecting to a running dm Server instance with a JMX client now shows you a Repository group. Under this group, each configured repository (with the exception of chained repositories) has a bean that returns synopses of all of the artifacts contained inside. The bean also exposes a method for returning the entire, detailed ArtifactDescriptor for a given bean based on it’s type, name, and version.

When managing and transforming as many bundles as are included in the the SpringSource Enterprise Bundle Repository, it becomes very difficult to remember what packages are boot delegated, exported from the system bundle, or from other bundles in your system. This information is important because you probably don’t want to import packages that are boot delegated, you probably do want to import system bundle packages at “0”, and you want to define custom imports for all others. Remembering which packages are in each of these categories ends up being a bit error prone and defining template entries for them can be time-consuming.