Convert to use bnd-maven-plugin

[bjhargrave]

We also add a resolve check to confirm the OSGi metadata can resolve.

I also tidied up some pom metadata which is used for OSGi metadata.

Two things to note:

1. This changes the Bundle-SymbolicName of the jar to the default which is the artifactId (which is also what assertj-core uses). It was org.assertj.guava. If we want to retain the original Bundle-SymbolicName, then we will need to set it in the Bnd configuration and the verify.bndrun file.
2. The verify check would fail since the jar imports org.assertj.core.internal which is not exported by assertj-core. So this is temporarily ignored by the -runsystempackages statement in the verify.bndrun file.

[scordio]

1. This changes the Bundle-SymbolicName of the jar to the default which is the artifactId (which is also what assertj-core uses). It was org.assertj.guava. If we want to retain the original Bundle-SymbolicName, then we will need to set it in the Bnd configuration and the verify.bndrun file.

Could the different symbolic name cause compatibility issues in the OSGi world? If not, I'd go as you did, using the same pattern as assertj-core.

The verify check would fail since the jar imports org.assertj.core.internal which is not exported by assertj-core. So this is temporarily ignored by the -runsystempackages statement in the verify.bndrun file.

Perfect, we'll make sure to remove that once #70 is fixed.

[bjhargrave]

Could the different symbolic name cause compatibility issues in the OSGi world?

Not really. At runtime, no one is likely to care about the BSN. It is more referenced during tool time if the tooling uses BSNs. So any downstream user may need to update such tool inputs when the update is released. But maven and gradle builds typically reference the jar via maven GAV (which is not changing).

When the assertj-core project switched to bnd-maven-plugin in 3.15, it also made the the BSN change (from org.assertj.core to assertj-core) and we had to adjust in the Bnd project. bndtools/bnd@00a9d54#diff-098e0861cd307b703acf27acb89560edf8bea267d2add2be2e758526215aabf0L3

But the real reason this change would not be a problem is #70 which means no one could use the current jar in OSGi at the moment. So the BSN change is quite safe :-)