Skip to content
This repository has been archived by the owner on Dec 9, 2018. It is now read-only.

Do not show unresolvable bundles in the repository view for bndrun #1208

Open
cschneider opened this issue Nov 5, 2015 · 9 comments
Open
Milestone

Comments

@cschneider
Copy link

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.

@bjhargrave
Copy link
Member

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

@cschneider
Copy link
Author

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:
osgi.unresolvable;filter:="(&(must.not.resolve=)(!(
must.not.resolve=
)))"

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.
An easy check would be just on the requirement namespace "osgi.unresolvable".

@bjhargrave
Copy link
Member

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:

Require-Capability: compile-only

so api bundles created from the bndtools enRoute templates will have that.

The OSGi companion jars do:

Require-Capability: osgi.compile.time.only; filter:="(&(must.not.resolve=*)(!(must.not.resolve=*)))"

So there are many ways a bundle could mark itself to be unresolvable. I am not sure how bndtools could detect them all.

@cschneider
Copy link
Author

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.
org.osgi.service.resolver.ResolutionException: Unable to resolve <> version=null: missing requirement osgi.enroute.base.api

I think the error message could show that the requirement
osgi.unresolvable;filter:="(&(must.not.resolve=)(!(must.not.resolve=)))"
can not be fulfilled.

@bjhargrave
Copy link
Member

Yes, I do agree the messages out of the resolver are not often useful.

@pkriens
Copy link
Member

pkriens commented Nov 13, 2015

We need to add an OSGi unresolveable namespace

https://osgi.org/members/bugzilla/show_bug.cgi?id=2884

@bjhargrave
Copy link
Member

OSGi should define an osgi.unresolvable namespace and bndtools could then recognize that and not offer the bundle.

@bjhargrave bjhargrave added this to the 3.2 milestone Nov 13, 2015
@bjhargrave bjhargrave modified the milestones: 3.3, 3.2 Apr 29, 2016
@bjhargrave bjhargrave modified the milestones: Someday, 3.3 Jul 22, 2016
@renatoathaydes
Copy link

Was this ever solved? Do we now have a standard way to make a bundle explicitly unresolvable?

@bjhargrave
Copy link
Member

OSGi did define an osgi.unresolvable namespace which will be part of the forthcoming R7 release.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants