Based on bnd 2.0
Bndtools 2.0 integrates the reference implementation of the OSGI Release 5 Resolver specification. We can now create run descriptors based on a very small number of “core” bundles that define our application, and allow all other dependencies to be automatically added through resolution.
This includes not just static dependencies arising from package imports, but also extender bundles (e.g. Declarative Services or Blueprint), service providers, or any arbitrary capability defined with
A run descriptor (bndrun file) is a description of an application, including all of the bundles and configuration required to run it. Previously these files were only used to launch in testing or debugging mode from Bndtools. However they can now be exported to a standalone executable JAR file, which precisely reproduces the runtime configuration used in testing.
The export feature is available both from the Bndtools GUI and as a bnd command and ANT task.
In version 1.0, Bndtools included a Diff and Release tool that compared bundles with their released version in a repository, and suggested the correct versions for the exported packages and the bundle itself. However it was still possible for developers to forget to run the tool, and thereby fail to indicate changes that had been made.
Now, the Diff/Release functionality has been pushed down into bnd and incorporated into the build process. This means that bnd will automatically check versions, and optionally break the build when they do not accurately reflect the changes made in the code. Thus developers can catch errors before checking in code, and/or they can be caught by a continuous integration server.
Bnd and Bndtools now support the
@ConsumerType annotations on API interfaces. These define the role of that interface within the service contract, and thus how implementers must be versioned.
For example if a bundle implements an interface annotated with
@ProviderType, it is now known to be provider and will import the API using a narrow version range such as
[1.0, 1.1). On the other hand, if our bundle only implements
@ConsumerType interfaces then it uses a normal consumer import range e.g.
Bndtools 2.0 adds decorators to the Eclipse Package Explorer for exported and excluded packages. These enable you to see at a glance:
In Bndtools 1.0 the incremental project builder was inefficient and intrusive, occasionally even blocking the user from working while it carried out certain tasks. The new builder in 2.0 minimises the work it needs to do by being smarter about dependencies, and as a result is faster and much less intrusive.
Apache ACE is a software distribution framework that allows you to centrally manage and distribute software components, configuration data and other artifacts to target systems. Bndtools now supports deploying directy to an ACE server from within the IDE.