Changes in 3.2.0

Bnd 3.2.0

For Bndtools 3.2.0 changes, see https://github.com/bndtools/bndtools/wiki/Changes-in-3.2.0.

Bnd Maven Repository

We've added a new repository plugin for Maven repositories, aQute.bnd.repository.maven.provider.MavenBndRepository, that replaces the Aether repository plugin. This repository plugin provides full support for Maven repositories. It can handle the following use cases:

• Local repository – Bnd can put built bundles directly in the local repository. This defaults to ~/.m2/repository but can be specified by the maven.repo.local system property.
• Remote repository – Publish snapshots and releases to the repository. Snapshot are properly managed. The remote repository URL can also be a file: URL to publish to a file system.
• Support for proxies and credentials.

There is a tutorial on the OSGi enRoute website and an example. These are the further links:

• Maven Bnd Repository – Overview of the plugin.
• -connection-settings – Explains how to set credentials and proxies.
• -maven-release – Specifies how to set options on the release process.
• -buildrepo – Shows how to built bundles can be placed directly into the local repository.

Bnd Maven Plugin Changes

bnd-maven-plugin

• When generating the Bundle-Version manifest header, previous versions of this plugin always replaced the string SNAPSHOT in the version qualifier with the value of the Bnd ${tstamp} macro. The plugin now instead sets the Bnd instruction -snapshot: ${tstamp}. If the qualifier equals SNAPSHOT or ends with -SNAPSHOT, the value SNAPSHOT is replaced with the the value of the Bnd ${tstamp} macro. Using the -snapshot instruction allows the user to override the plugin behavior in the project's bnd file. For example, to retain the string SNAPSHOT in the version qualifier, set -snapshot: SNAPSHOT in the project's bnd file.
• Performance improvements were made for incremental building with M2E. The plugin will avoid work and writing output if none of the input files to the bundle are changed.
• A <bndfile> configuration element is defined to allow the specification of an alternate path for the project's bnd file. This path can be absolute or relative to the project's base directory.
• A <bnd> configuration element is defined to allow the Bnd instructions to be specified in the pom file. This will generally be done via a <![CDATA[]]> section in the <bnd> element. The <bnd> element will not be used if the project has a bnd file.
• If Bundle-SymbolicName is not set in the project's bnd file, its value will default to the project's artifactId.
• If Bundle-Name is not set in the project's bnd file, its value will default to the project's name.

Bnd Gradle Plugin Changes

• TBD

Other Notable Changes

• ProjectBuilder, used for Workspace model builds, is changed to use the source output folder, e.g. bin folder, as the default contents of the bundle if the project does not specify any of the following instructions: Private-Package, Export-Package, Include-Resource, -includeresource, or -resourceonly. If the project specifies any of these instructions, then they will fully control the contents of the bundle. This change will make the default behavior more like maven or gradle builds where the source built in the project is included in the resulting bundle without having to specify that it should be included.

Backwards compatibility

• The bnd-maven-plugin changed how SNAPSHOT is replaced with ${tstamp} in the Bundle-Version header value. See above for details.
• The bnd-maven-plugin changed the default value of the Bundle-SymbolicName header from the name of the project's base directory to the project's artifactId.
• Bnd 4.0, planned for Spring 2017, will move to Java 8 as the base runtime.
• The Bnd DS, metatype and versioning annotations are deprecated and support for them will be removed in Bnd 4.0. Please make plans to migrate to the OSGi Release 6 specified annotations which now offer more features than the bnd annotations.

Known Issues

• None at this time.