ebr-maven-plugin should have capability to reuse all artifact OSGi metadata about ebr HOT 9 CLOSED

As I raised this in the PR ... The point about EBR is generating bundles from recipes.

If there is an artifact with OSGi metadata already then there are two options:

1. consume it as is from wherever it comes from (Maven Central?)
2. repackage it (for signing and other modifications)

In case 1 EBR should not be used at all. Just consume the artifact directly.

In case 2 the bundle symbolic name must be changed to reflect that this is not the original artifact. This requires the osgi.bnd file, doesn't it?

from ebr.

I think in (1), the project still has to sign it in order to include it in their repository. The other issue is if everyone is signing + bundling their own version of the same artifact, when everything gets combined under simrel there could be duplicates. I know @mickaelistria is doing some work in Tycho to hopefully make all of this work properly in the future.

If any additional changes are required (other than signing) where there's content being modified in the manifest, it's best to just have the osgi.bnd being used.

There's certainly some cases we could probably push back more and ask the projects (even some hosted at Eclipse) to generate their own p2 metadata rather than pushing it through Orbit.

from ebr.

It's more @laeubi who's doing this work.
I agree with @guw here, consuming existing OSGi bundles as-is from external repos is not something for EBR to care about, Tycho can do it, PDE can do it (thanks to @laeubi 's work).
We could imagine a separate utility to amend existing OSGi jars (add signatures and consequently change Bundle-SymbolicName & Bundle-Vendor). As this could be a relatively standard case, we may be able to achieve that without a osgi.bnd file, by implementing a simple utility that can take of that; so it could be easily reused in any context.
However, it's maybe worth calculating whether just adding signatures upstream would be profitable. Or, if basically just getting rid of constraints over signatures of external jars would be a good idea (since who really verifies the binaries anyway before running OBR or Tycho?).

from ebr.

I actually have never tried that (as its kind of strange usage) but for the sake of signing/integration it should work to simply have an EMPTY bnd file, Bnd should then read all manifest entries from the existing jar and simply use that metadata so it would be a no-op.

from ebr.

The other issue is if everyone is signing + bundling their own version of the same artifact, when everything gets combined under simrel there could be duplicates.

I'm not suggesting that. It's still valueable to have the bundle in Orbit and shared for multiple projects. However, in this case having the osgi.bnd file in Orbit Git to adjust the bundle symbolic name and vendor is IMO a better approach than silently signing a third party artifact with Eclipse.org signature. Although technical doable it's wrong from a compliance perspective. The artifact is no longer the original. It has been vetted and reviewed by Eclipse committers. This should been properly attributed.

If - however - the artifact is consumed directly from an external source it should not be signed. We have no control of the other source and it may change randomly. (Disclaimer: there are some guarantees and trust around Maven Central that this should not happen for releases. It might be ok but still feels wrong to me.)

from ebr.

The other issue is if everyone is signing + bundling their own version of the same artifact, when everything gets combined under simrel there could be duplicates.

I'm not suggesting that. It's still valueable to have the bundle in Orbit and shared for multiple projects. However, in this case having the osgi.bnd file in Orbit Git to adjust the bundle symbolic name and vendor is IMO a better approach than silently signing a third party artifact with Eclipse.org signature. Although technical doable it's wrong from a compliance perspective. The artifact is no longer the original. It has been vetted and reviewed by Eclipse committers. This should been properly attributed.

I would be fine with retaining an osgi.bnd for the sake of Bundle-SymbolicName, but then could there at least be a way to not have Import/Export-Package re-calculated ? I believe they still get re-generated even when present in the artifact manifest.

from ebr.

I would be fine with retaining an osgi.bnd for the sake of Bundle-SymbolicName, but then could there at least be a way to not have Import/Export-Package re-calculated ? I believe they still get re-generated even when present in the artifact manifest.

FWIW, the EBR plug-in is configured in the parent pom.xml for recipes. Did you play with the configuration? It might be possible to avoid the osgi.bnd file.

Under the hood EBR ist just the Apache Felix Maven Bundle plug-in with some conventions applied.
http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html

I don't know if bnd has an operation mode to re-use existing headers. The point of bnd is to generate the headers. Thus, I think the easier path might be to enhance the create-recipe mojo to look into an existing manifest and copy the headers into the osgi.bnd file.

from ebr.

Thanks for the reference! From some local testing, I'm having some success by adding the manifest (if ${project.build.directory}/dependency-bin/META-INF/MANIFEST.MF exists) to the <_include>..</_include> header. It can probably be overridden by individual bundle recipes as needed.

from ebr.

Closing out old issues that are not likely to be addressed going forward. https://github.com/eclipse/ebr#history

from ebr.