Warn clearly when importer discovery fails due to missing importer factories / classloader mismatch

[redcatbear]

Problem

When OpenFastTrace is embedded in another application, importer discovery can silently fail if the current thread context classloader does not expose the importer implementations.

In that situation, the normal import flow is still executed, including:

• OftRunner.importItems(settings)
• ImporterServiceImpl#createImporter()
• MultiFileImporterImpl#importAny(settings.getInputs())

but no importer factories are discovered for supported files, so the trace result ends up with 0 imported specification items.

Why this is confusing

From the caller side, the input path is valid and points to a project directory with supported OFT files.

The failure mode looks like:

• import runs
• no exception is thrown
• trace completes
• result is ok - 0 total

The only hint is per-file logging like:

• Found no matching importer for file '...'

In embedded/plugin environments this is too easy to miss.

Root cause

OFT importer discovery uses ServiceLoader with the current thread context classloader:

• ServiceOrigin.forCurrentClassPath() uses Thread.currentThread().getContextClassLoader()
• ClassPathServiceLoader loads services from that classloader
• importer factories are filtered to that same classloader

If the thread context classloader is not the one that loaded the OFT importer jars, importer detection effectively fails.

Expected behavior

OFT should make this failure mode much more visible.

Possible improvements:

1. Emit a clear warning when no importer factories are available at all for the current import context.
2. Emit a summary warning when a directory import scans files but no supported importer could be resolved for any file.
3. Include a hint that this may be caused by classloader setup in embedded/plugin use cases.
4. Optionally expose a small diagnostic API so embedders can check whether importer factories were discovered before running a trace.

Actual behavior

Directory import succeeds structurally but imports zero items, which later looks like an empty trace instead of an importer discovery problem.

Reproduction idea

Embed OFT in an application/plugin where:

• OFT core is on the plugin/application classpath
• importer jars are present
• the thread context classloader differs from the OFT/plugin classloader

Then call:

oft.importItems(
    ImportSettings.builder()
        .addInputs(projectRoot)
        .build()
);

Expected result in this setup today: 0 imported items unless the caller manually switches the thread context classloader.

Suggested wording

A warning like this would already help a lot:

No matching importer factories were discovered for scanned inputs. This may indicate missing importer plugins or a classloader mismatch in an embedded environment.

Additional note

In our case, switching the thread context classloader to the plugin classloader before invoking OFT import/reporting fixed the issue.