Skip to content
This repository has been archived by the owner on Dec 9, 2018. It is now read-only.

Changes in 3.1.0

Jump to bottom
BJ Hargrave edited this page Feb 13, 2017 · 24 revisions

Bnd/Bndtools 3.1.0

Bnd Maven Plugin Changes

The 3.1 release includes two new Maven plugins to enhance the integration of Bnd and Maven.

bnd-indexer-maven-plugin

The bnd-indexer-maven-plugin is a bnd-based plugin that creates OSGi Indexes of bundles. It creates an OSGi repository index — suitable for use in Bndtools for resolving and provisioning — from a set of Maven project dependencies.

The project dependencies are referenced in the remote repositories where they are deployed (i.e. they are not republished in a single artifact as they would be when using the maven-assembly-plugin).

The output is an XML file, and a parallel gzipped version of the XML. When deployed to a remote repository these can be used to efficiently host an OSGi index.

Documentation for the bnd-indexer-maven-plugin is available here

bnd-baseline-maven-plugin

The bnd-baseline-maven-plugin is a bnd-based plugin that baselines the output of a Maven project against a previously released project. By default the plugin will automatically identify the previously released version to baseline against, however the plugin can be explicitly configured to baseline against any artifact in the maven repository.

By enabling baselining using the bnd-baseline-maven-plugin you can ensure that your maven build will fail unless versions are correctly updated. This prevents developers from accidentally forgetting to update versions, and avoids situations where versions are repeatedly updated "just in case".

bnd-maven-plugin

The bnd-maven-plugin is also updated to:

  • Fix a bug that prevented the use of pom properties in the bnd file.
  • Allow using of settings properties in the bnd file.
  • Support the bnd -include instruction so you can include other bnd files.
  • Set the project.outputdir, project.buildpath, and project.sourcepath bnd properties which can be used in the bnd instructions.
  • Use the M2E incremental build API to allow M2E to detect which files have been changed.

New Bndtools Template System

Bndtools 3.1 makes it much easier to define templates for new project and launch descriptors.

Previously templates could only be defined in an Eclipse plug-in, which meant figuring out how to get that plug-in installed into Eclipse using p2. Now, a template can be defined using any bundle in a repository, or the workspace itself. This means that you can define a template project in your workspace and immediately use it to generate additional projects from that template.

To get started building your own templates, create a new Bndtools project using the "Project Template Project". The generated template will be usable immediately, though not particularly useful. Refer to the readme.txt file in the new project for full details of how to customising the template.

Standalone BndRun Files

Bndtools now supports bndrun files that are disconnected from a traditional bnd workspace. This means you can create a bndrun file anywhere, e.g. in a plain Java or Maven project with no cnf folder.

The bndrun must declare a -standalone instruction that lists repository URLs. These repositories will be used for resolving and running. For example:

-standalone: \
    https://raw.githubusercontent.com/bndtools/bundle-hub/master/index.xml.gz,\
    ${user.home}/.m2/repository/repository.xml

-runrequires: \
    osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.command)',\
    osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.shell)'

-runfw: org.apache.felix.framework; version=5

Referencing Bundles by Content Hash

Bnd now supports referencing bundles (e.g. in -buildpath and -runpath) using their SHA-256 content hash. For example:

-buildpath: slf4j.api; version=hash; hash=7fe83bfd5999fa4ef9cec...

The repository implementation is able to look up the content using the hash string rather than the BSN. The BSN is still provided, and bnd checks that the resource with the specified hash actually has that identity.

The default hash algorithm is SHA-256. You can specify a different algorithm by prefixing the hash string (however note that OSGi Release 5 Repository indexes always use SHA-256, so this feature is mainly for future use):

-buildpath: slf4j.api; version=hash; hash=SHA-512:aa2f01e2404972a...

In later versions of Bndtools we will introduce tooling to make hash dependencies easier to work with. For example, right-click on a versioned dependency like slf4j-api; version=1.7 and lock it down to the current known hash.

Bnd Gradle Plugin Changes

biz.aQute.bnd.builder plugin

The biz.aQute.bnd.builder plugin for non-Workspace builds now adds a baseline configuration and a baseline task of type Baseline which baselines the bundle generated by the jar task against the prior version of that bundle in the repositories.

New Baseline task type

A new Baseline task type is added for non-Workspace builds.

Bundle task type enhancements

The Bundle task type for non-Workspace builds has been enhanced. It now supports the bnd -include instruction so you can include other bnd files. It also sets the project.name, project.outputdir, project.buildpath, and project.sourcepath bnd properties which can be used in the bnd instructions.

Other Notable Changes

  • Bndtools is now built targeting Eclipse Luna 4.4.2. So it requires Eclipse Luna 4.4.2 or later to run.
  • Bndtools supports manually generating an OSGi Repository Index from a directory.
  • biz.aQute.launcher, biz.aQute.junit, and biz.aQute.tester are now available from Maven Central and JCenter.
  • OSGi Metatype annotation processing will prefer metatype namespace v1.2.0 unless v1.3.0 is needed.
  • OSGi DS annotation processing will check that the component implementation class is compatible with the declared service.
  • Bnd supports new base64, digest and uri macros.
  • Bnd now parses bnd files directly, rather than using java.util.Properties. This allows bnd to report bnd file errors that otherwise went unnoticed. This includes errors like missing \ at the end of a line when the next line starts with whitespace. So updating to bnd 3.1 may expose problems in your bnd files of which you were unaware.
  • Bnd now supports VerifierPlugins.
  • Bnd's -donotcopy instruction is extended to also match paths in addition to names. So you can now say -donotcopy: .*/foo/.*.
  • Bnd's javac.source and javac.target properties will now default to the version of Java in which bnd is running. They used to default to 1.5 always.

Backwards compatibility

  • Bnd's -donotcopy instruction is extended to also match paths in addition to names. If your bnd file had -donotcopy: .*foo.*bar.*, this pattern will now match /xxx/foo/yyy/bar/something as well as /xxx/foobaxbar. Take care to examine your -donotcopy instructions to ensure this change does not cause problems.
  • The Bnd annotations will be deprecated in a future release of Bnd. Please make plans to migrate to the OSGi Release 6 specified annotations which now offer more features than the bnd annotations.
  • Bnd's javac.source and javac.target properties will now default to the version of Java in which bnd is running. It is recommended you set them to a specific value in your build to avoid surprises when running your build with a different version of Java.

Known Issues

  • A comment line in a bnd file ending in \ is incorrectly continued onto the next line.
Clone this wiki locally