[search] Mandatory attributes thwarts quickfix search/repoview search

[kriegfrj]

I'd been having some mysterious cases where the quickfix would fail to recommend a bundle. Most recently, I was trying to refactor JUnitShortcut into a new bundle, and when I moved it into the new bundle was getting an "Unknown Method" error due to an incomplete type hierarchy. No recommendation was coming up even though I know that the appropriate bundle is available in one of the repos.

The missing class was org.eclipse.ui.texteditor.StatusTextEditor. It is in bundle org.eclipse.ui.workbench.texteditor.

I traced through BuildpathQuickFixProcessor only to find that it is correctly identifying the missing class and passing the correct arguments to the WorkspaceClassIndex. The problem is in the search: the org.eclipse.ui.texteditor package is exported with the attributes texteditor="split";mandatory:="texteditor". Because we do not provide the mandatory attribute when we do our search, it doesn't return any results.

The same problem happens if you try and do a package lookup in the repository search GUI.

[kriegfrj]

I've had a quick look but I can't see a way around this on the search client side. You need to know in advance what the mandatory attributes are in order to supply something. For example, in the texteditor example above, all you need to do is texteditor=* and the search will match, but you need to have a-priori knowledge of the result in order to know to put the texteditor=* into the search string in the first place. But if you already know that, then you already know which bundle you're looking for anyway.

So I can't see an easy way around this with the current code. The only thing I can think of is a parallel implementation/option on findProviders() for this purpose, which can bypass the ordinary mandatory attribute matching. It would be appropriate for (eg) the RepositoryView search and the quick fix processor to ignore mandatory attribute matching when trying to find packages/classes.

This would be a fairly simple patch (I think) but as it touches some core code I thought I'd float the idea here first before I go too far down this path. Particularly interested in hearing from @pkriens as he initially wrote the classindex.

[bjhargrave]

I don't think we want to mess with not honoring mandatory support. This is a situation Eclipse has created with their API in how they have had non-cohesive packages and then split them into multiple bundles with a facade bundle that rejoins the packages using Require-Bundle. We do not want bnd to make import package statements which specify these split attributes. I think this is just something you will need to suffer through when you develop against eclipse API due to how they evolved their API.

[kriegfrj]

I agree, I'm not seeking to fix the import package generation. The macros in the Bnd workspace already do a good job of adding the necessary attributes.

But it would be nice to have a search facility that can find matching resources without having to supply the mandatory attributes. Requirement matching is a subset of generic search functionality.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

[github-actions[bot]]

This issue has been automatically closed due to inactivity. If you can reproduce this on a recent version of Bnd/Bndtools or if you have a good use case for this feature, please feel free to reopen the issue with steps to reproduce, a quick explanation of your use case or a high-quality pull request.