Do not show unresolvable bundles in the repository view for bndrun #1208
Comments
How would bndtools know that the bundle is not resolvable? I don't think it is easy to look at a bundle, by itself, and decide there is no possible way to resolved it |
Of course there is no general way to determine if a bundle can never be resolved. As far as I understood though there is a pattern that is used on the new api packages to mark them as unresolvable. In osgi.enroute.base.api there is the requirement: So bndtools could simply detect this pattern and filter out those bundles. Alternatively it could allow to add the bundle but warn the user right away that the bundle is not meant to be installed into OSGi. |
Well there are many different ways bundles have attempted to mark themselves unresolvable. There is the Unresolveable annotation way which you mention which is used in the enRoute bundles. The enRoute project template in bndtools does:
so api bundles created from the bndtools enRoute templates will have that. The OSGi companion jars do:
So there are many ways a bundle could mark itself to be unresolvable. I am not sure how bndtools could detect them all. |
That might be difficult. I thought there was one "standard" way to say a bundle should be unresolvable. If it is too difficult to identify unresolvable bundles then the error message on resolve should at least show the requirement that can not be resolved. This is the error message I get when I try to install the enroute base api bundle. I think the error message could show that the requirement |
Yes, I do agree the messages out of the resolver are not often useful. |
We need to add an OSGi unresolveable namespace |
OSGi should define an osgi.unresolvable namespace and bndtools could then recognize that and not offer the bundle. |
Was this ever solved? Do we now have a standard way to make a bundle explicitly unresolvable? |
OSGi did define an |
Some of the newer API bundles use a special requirement to make sure the bundle can never be resolved.
Currently such bundles can be dragged into the run requirements and when doing a resolve it fails with a not very clear error message.
As these bundles can never be resolved it would make sense to not provide them in the repository view at all.
The text was updated successfully, but these errors were encountered: