Is it a known issue that the bnd-resolver-plugin (or rather the underlying felix resolver) memory usage explodes when confronted with a larger set of bundles to resolve / to choose from?
Yes, it is. See Resolving - OSGi’s Best Kept Secret? | OSGi enRoute “Resolving & Repositories”.
AFAIK this is not considered a problem, because in an enterprise (project) environment, you will obviously have this “carefully curated repository”. Your configuration and/or release manager meticulously reviews each library/bundle that your team plans to include into you project and takes care of deprecating old versions and allowing new ones to be added, thus limiting your SBOM in a way that allows the resolver to run smoothly. 
For not so carefully managed environments (i.e. when you assume [compatible] new versions to always be better and want “automatic upgrades” – the common maven approach) I have helped myself with Bnd Indexed Maven Repository | de.mnl.osgi . It still requires some curating, but it usually provides something that the resolver can handle (with limited memory and within limited time).
I keep the results of the resolution (the bndrun files) in git and compare each new resolution against the previous one. This allows me to review the updates of the libraries used for resolution with a limited effort.
What @mnlipp wrote is totally correct.
Some more context and advice though. If presented with too many possibilities to run in circles or better that the possible resolution tree results in incompatible crossings. This usually happens when you have multiple bundles that export similar packages. The most common case here being multiple versions of the same bundle (two Versions of felix scr) or two implementation of the same Specifications (felix and equinox EventAdmin). Luckily the resolver tells us about it, but only if we cancel the resolve job before it is stuck.
You need to run the resolve in bndtools and cancel the job after a couple of seconds (the first situation usually appears quite fast). The resolve result now gives you a couple of lines of the resolvers log file. It also shows the location of the file (you need to mark the don’t delete when you close the window).
I don’t have an example at hand, but you will find some prominent entries where it complains about multiple chains and what the chains are. With this you know what to remove from your repositories or what to blacklist. Just try to resolve the first issue and then resolve again. Rince and repeat until it works.
Oh yes… now I remember. I had a similar problem already some time back: the resolver would churn for ages trying to find a valid configuration and would never tell me what is actually going wrong.
The problem here is: I am using the bnd-maven-plugin and as far as I can tell, there is no way to configure the plugin to actually log what is going wrong. There is also no way to cancel the resolve job when using the bnd-maven-plugin in such a way that it would print some last lines of problems. Cancelling the build just cancels the build - no helpful information.
What I had to do way to connect with a remote debugger to the build process and set trace points in strategic places in the org.apache.felix.resolver.ResolverImpl so that I would get an idea of what is happening…
Is there any better way of doing this than having to use a remote debugger and trace points?!
I believe the instruction you want is https://bnd.bndtools.org/instructions/resolvedebug.html
Place this in the bndrun file being resolved.
I have tried it, but it does not seem to provide helpful information for me. Setting the level to 1, 2 or 3 provides progressively more information (a LOT of information for 2 and 3).
The information that helps me comes from a tracepoint in org.apache.felix.resolver.ResolverImpl.ResolveSession.setCurrentError(ResolutionError). There, I log the ResolutionError which produces output like e.g.
Uses constraint violation. Unable to resolve resource plugin-a [plugin-a version=1.0.0-SNAPSHOT] because it is exposed to package 'some.package' from resources plugin-b [plugin-b version=2.3.1] and plugin-c [plugin-c version=1.4.2] via two dependency chains.
Chain 1:
plugin-a [plugin-a version=1.0.0-SNAPSHOT]
import: (&(osgi.wiring.package=some.package)(version>=1.0.0)(!(version>=2.0.0)))
|
export: osgi.wiring.package: some.package
plugin-b [plugin-b version=2.3.1]
Chain 2:
plugin-a [plugin-a version=1.0.0-SNAPSHOT]
import: (&(osgi.wiring.package=some.other.package)(version>=1.0.0)(!(version>=2.0.0)))
|
export: osgi.wiring.package: some.other.package; uses:=some.package
export: osgi.wiring.package=some.package
plugin-c [plugin-c version=1.4.2]
There is a org.apache.felix.resolver.ResolverImpl.m_logger which the BndResolver populates with biz.aQute.resolve.ResolverLogger that delegates to an biz.aQute.resolve.InternalResolverLogger.InternalResolverLogger(ResolverLogger):
public static RunResolution resolve(Project project, Processor actualProperties,
Collection<ResolutionCallback> callbacks, ResolverLogger resolverLogger) {
if (callbacks == null)
callbacks = Collections.emptyList();
ResolverLogger logger = resolverLogger == null ? new ResolverLogger() : resolverLogger;
try {
try {
ResolveProcess resolve = new ResolveProcess();
Resolver resolver = new BndResolver(logger);
I didn’t find a call to biz.aQute.resolve.RunResolution.resolve(Project, Processor, Collection<ResolutionCallback>, ResolverLogger) in particular from the bnd-maven-plugin that would allow me to increase the log level for the logger and/or to redirect it through the Maven logging system. I also didn’t find a system property to override the log level in the ResolverLogger. I am also not 100% if the ResolverImpl would actually log helpful information through that logger.
Is there a way to see the errors reported in the ResolverImpl’s session when using the bnd-maven-plugin without having to resort to using a tracepoint?
Thanks @rec for bringing that up in the bnd call yesterday.
So are you saying that it would be helpful for you to have a System property (or something) to set the loglevel here in biz.aQute.resolve.RunResolution.resolve(Project, Processor, Collection, ResolverLogger)
@rec please see Runresolution should consider loglevel set via -resolvedebug by chrisrueger · Pull Request #6117 · bndtools/bnd · GitHub if this is helpful for debugging.