fix(#707): reduce the simple-no-file fix to the service entry and add a regression test (backport of #708)

[jbonofre]

Backport of #708 to camel-karaf-4.18.x. Relates to #707.

Why this is needed on top of #714

#714 already backported the first commit of #708 (Added simple-no-file support, on this branch as e1caf2e). #708 was subsequently reworked, and that follow-up commit has not reached 4.18.x. This PR cherry-picks it (-x), bringing 4.18.x to the same final state as main.

What the follow-up commit changes

The service entry the fix relies on is loaded by name by Activator.BaseResolver; the @Language annotation on the class is never read at runtime. So the extra machinery that landed with #714 is unnecessary and actively harmful:

• Drop the local copy of SimpleNoFileLanguage — it shadowed the upstream class in the shaded jar, so a future Camel change to SimpleNoFileLanguage would have been silently overridden with no build failure. The upstream class is already present and unchanged in the shaded bundle.
• Drop the camel-api / camel-support dependencies the local copy needed to compile — they were compile scope and, because the root pom sets createDependencyReducedPom=false, would have leaked into the bundle's published pom and onto every consumer's classpath.
• Restore the conventional org.apache.camel* export → narrowed to org.apache.camel.language* — keeping the wide 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 core/camel-api and core/camel-support already provide.
• Replace the shade IncludeResourceTransformer with a <resource> entry — the module's <resources> block overrides Maven's default src/main/resources, which is why the file did not reach the bundle on its own. The transformer would also hard-fail the build with duplicate entry if Apache Camel ever ships its own simple-no-file service file, whereas the resource path lets shade dedupe silently.
• Add the ASF licence header the service file was missing — apache-rat rejected it, which breaks the release profile. java.util.Properties, used to parse the file, ignores the # comments. The header also carries a note recording why camel-karaf ships an entry Camel deliberately omits, so a future Camel upgrade does not drop it.
• Add a Pax Exam regression test in tests/features/camel-core driving a pollEnrich with a dynamic file endpoint — the scenario from simple-no-file language causes NoSuchLanguageException #707.

Diff vs. #708

The tree of the touched paths is identical to the head of #708, apart from the 4.18.3-SNAPSHOT vs 4.18.2-SNAPSHOT parent versions:

$ git diff HEAD pr-708-head -- core/camel-core-languages tests/features/camel-core
  core/camel-core-languages/pom.xml   -<version>4.18.3-SNAPSHOT</version> +<version>4.18.2-SNAPSHOT</version>
  tests/features/camel-core/pom.xml   -<version>4.18.3-SNAPSHOT</version> +<version>4.18.2-SNAPSHOT</version>

The cherry-pick applied cleanly, with no conflicts.

Verification on this branch (JDK 17)

• mvn install -pl tests/features/camel-core -am -DskipTests — BUILD SUCCESS; the new route supplier and itest compile against the 4.18.x test-support classes unchanged.
• Built camel-core-languages bundle: 412 KB (not 1.9 MB), Export-Package limited to org.apache.camel.language.*, SimpleNoFileLanguage.class present from the upstream shaded jar, and the service entry present with its header.
• apache-rat:check — 0 unapproved licences on both touched modules.
• The Pax Exam itest itself was not run locally (it needs the full distribution build); it is left to CI. It was verified 5/5 on main in fix(#707): register the simple-no-file language in the camel-core-languages bundle #708, including that removing the service entry makes testCamelPollEnrich fail.

AI-generated (Claude Code) on behalf of JB Onofré.