---
title: "bnd, Bndtools, Maven, Gradle, and baselining"
chapter: "10"
---

# bnd, Bndtools, Maven, Gradle, and baselining

bnd is the core tool for creating and analyzing OSGi artifacts. Bndtools adds
an Eclipse workspace and runtime experience; Maven and Gradle plugins integrate
the same analysis into ordinary builds.

## Build by analysis

bnd reads compiled bytecode, determines referenced packages, calculates imports,
applies export instructions, generates DS/Metatype descriptors, and verifies
metadata.

```text
Bundle-SymbolicName: com.acme.charging.core
Export-Package: com.acme.charging.api;version=1.4.0
-dsannotations: *
-metatypeannotations: *
-reproducible: true
```

Avoid `Import-Package: *` as a thoughtless handwritten manifest. In bnd, a final
`*` instruction means “include remaining calculated imports” and is often
appropriate after intentional overrides.

## Resolution

Use `.bndrun` requirements plus repositories to calculate `-runbundles`.
Commit or reproduce the resolution and fail CI when the declared runtime no
longer resolves.

## Semantic versioning and baselining

bnd compares a new API with a previous bundle:

- compatible addition usually increments minor;
- breaking API change increments major;
- implementation-only fix increments micro.

Provider and consumer interface roles affect compatibility advice. Baselining
turns version discipline into build evidence.

## Maven and Gradle

Use current bnd plugins, pin versions, keep generated manifests inspectable,
and run integration tests against the produced JAR—not just IDE output.
Maven coordinates are repository identity; they do not replace OSGi metadata.

## Reproducibility

Pin repositories, plugin versions, execution environment, framework, and
runtime closure. Sign releases, generate an SBOM, and compare the deployed
digest to CI output.

## Feynman check

bnd does not “make a JAR modular” by magic. It discovers bytecode relationships
and writes a contract. You still decide the public API and acceptable ranges.