fix(#707): register the simple-no-file language in the camel-core-languages bundle

[robinvish2794]

Fixes #707.

Problem

pollEnrich (or poll) driven by a simple expression fails in Karaf with:

org.apache.camel.NoSuchLanguageException: No language could be found for: simple-no-file
	at org.apache.camel.karaf.core.OsgiLanguageResolver.resolveLanguage(OsgiLanguageResolver.java:56)

PollEnrichReifier rewrites a simple expression to the internal simple-no-file language. Apache Camel ships no META-INF/services/org/apache/camel/language/simple-no-file — DefaultLanguageResolver resolves that name through a hardcoded branch instead:

if ("simple-no-file".equals(name)) {
    type = context.getClassResolver().resolveClass("org.apache.camel.language.simple.SimpleNoFileLanguage");
} else {
    type = findLanguage(name, context);
}

camel-karaf replaces that resolver with OsgiLanguageResolver, which looks languages up in the OSGi service registry and has no such branch. Its last fallback, a LanguageResolver service registered under resolver=default, no longer exists in Camel 4.18.1 (no artifact ships META-INF/services/org/apache/camel/language/resolver/default), so resolution ends in NoSuchLanguageException.

Fix

Ship the service entry in the camel-core-languages bundle. Activator then registers a LanguageResolver service with language=simple-no-file, and OsgiLanguageResolver finds it.

The class the entry points at, org.apache.camel.language.simple.SimpleNoFileLanguage, is already present and unchanged in the shaded bundle, and Activator.BaseResolver loads it by name from the service file.

Mirroring the flat-classpath branch inside OsgiLanguageResolver was considered and rejected: OsgiClassResolver loads through the route bundle's classloader, and route bundles do not import org.apache.camel.language.simple. Going through the service registry means the exporting bundle loads its own class, which is robust regardless of the consumer's wiring.

Changes

• core/camel-core-languages/src/main/resources/META-INF/services/org/apache/camel/language/simple-no-file — the service entry, with the ASF header and a note recording why camel-karaf ships an entry Camel deliberately omits, so a future Camel upgrade does not drop it.
• core/camel-core-languages/pom.xml — declare src/main/resources explicitly. The module's existing <resources> block replaces Maven's default resource directory, which is why the file would otherwise never reach the bundle.
• tests/features/camel-core — Pax Exam regression test driving a pollEnrich with a dynamic file endpoint, the scenario from the issue.

Verification

• The built bundle is identical to the one built from main except for the added service entry, with an unchanged Export-Package.
• CamelCoreITest: 5/5 pass. With the service entry removed, testCamelPollEnrich fails (mock://camel-poll-enrich-test Received message count. Expected: <1> but was: <0> — the route never starts), so the test does catch the regression.
• apache-rat:check passes on the module; it failed before the licence header was added, which would have broken the release profile.

Note on the changeset

The original commit also added a local copy of SimpleNoFileLanguage, camel-api/camel-support dependencies, and a narrowed Export-Package. Those have been removed as unnecessary, because the annotation they carried is never read at runtime:

• the local copy shadowed the upstream class in the shaded jar, so a future Camel change to it would be silently overridden with no build failure;
• the two dependencies were compile scope and, since the root pom sets createDependencyReducedPom=false, would have leaked into the bundle's published pom and onto every consumer's classpath;
• keeping the conventional org.apache.camel* export with those dependencies present makes bnd inline all of camel-api and camel-support into the bundle (412 KB → 1.9 MB) and duplicate-export packages that core/camel-api and core/camel-support already provide.

The shade IncludeResourceTransformer was likewise replaced by the <resource> entry: it would have hard-failed the build with duplicate entry if Apache Camel ever ships its own simple-no-file service file, whereas shade dedupes jar entries silently.

[jbonofre]

Rebased this branch onto current main (60b7548e1) and force-pushed, so the PR is back on a linear history over the 11 commits main picked up since b79bba8ad.

• The rebase was conflict-free, and the net diff is byte-identical to the pre-rebase one (4 files, +125 / -0). Both commits are preserved; the squash-merge will collapse them anyway.
• The CI failure on the previous head was CamelGooglePubsubITest, which is unrelated to this change — it is fixed on main by 60b7548 ("bump the Pub/Sub emulator image to a tag gcr.io still serves", fix(#745): bump the Pub/Sub emulator image to a tag gcr.io still serves #746). The rebase should clear it.
• The PR description still describes the changeset accurately, so it is unchanged.

@robinvish2794 heads-up: this PR's head is your fork's main branch, so the force-push rewrote it. To sync your clone:

git fetch origin && git reset --hard origin/main

For future PRs, a topic branch (e.g. fix-707-simple-no-file) rather than main avoids this.

Claude Code on behalf of Jean-Baptiste Onofré