Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make the usage of RepositoryPlugin <-> Repository more flexible in bnd (run)s #6480

Open
laeubi opened this issue Feb 20, 2025 · 3 comments
Open

Comments

@laeubi
Copy link
Contributor

laeubi commented Feb 20, 2025

One thing I noticed quite often now is that when using Bndruns programmatically (not sure if the same problem might occur elsewhere) to perform a resolve operation one sometimes get very strange could not resolve <<INITIAL>>... errors.

After some digging one finds that this is because there are two kind of "repositories":

  1. "bnd" repositories (like FileRepo) that are implemented as RepositoryPlugin and can be used to resolve e.g. bundle classpath and alike
  2. "osgi" repository, that is required to perform a resolve operation (e.g. FileSetRepository) that are usually also RepositoryPlugins

One example is biz.aQute.resolve.BndrunResolveContext.getAllRepos() where it only will get all that are OSGi Repository but this will of course not cover "plain" ones. This is very confusing because the usual bnd operations work, but the resolve suddenly fails.

I could think of two ways to resolve this:

  1. Make bndrun / maybe others "smarter" ...
  2. Have some kind of way to define a "converter" that is when I call aQute.bnd.service.Registry.getPlugins(Repository.class) automatically wraps RepositoryPlugins that do not implement that interface in a Repository thats uses the repository plugin as a backend.

One example is the "implicit" repository CachedFileRepo that come with each Workspace by default, one can use that for all operations in bnd except for resolve... for this purpose one has to explicitly add for example biz.aQute.tester.junit-platform even though it is part of the implict repository.

@chrisrueger
Copy link
Contributor

chrisrueger commented Feb 22, 2025

I stumbled on the two kinds of repositories too when I worked on the tags. But I didn't pay it much attention. But maybe somebody could explain the intention / reasoning behind this.

One example is the "implicit" repository CachedFileRepo that come with each Workspace by default, one can use that for all operations in bnd except for resolve

  1. Make bndrun / maybe others "smarter" ...

I just found this:

public boolean injectImplicitRepository(Run run) throws Exception {

Do you mean by "making smarter" to do something similar?

@laeubi
Copy link
Contributor Author

laeubi commented Feb 23, 2025

With the embedded repo I mean this one here:

class CachedFileRepo extends FileRepo {

it is a "normal" repo (that can lookup things by name and list all versions) but not an OSGi repo (that can resolve capabilities).

With "smarter" I mean this here biz.aQute.resolve.BndrunResolveContext.getAllRepos() it only uses Repository.class but not RepositoryPlugin.class (what needs to be wrapped so support identity lookups) types

@chrisrueger
Copy link
Contributor

but not RepositoryPlugin.class (what needs to be wrapped so support identity lookups) types

@laeubi
Have you seen any other place in the code which does this kind of "wrapping"? I tried having a look but I am getting a bit lost between all those BaseRepository, AbstractIndexedRepo, BridgeRepository etc.

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

No branches or pull requests

2 participants