Skip to content

Bump Sisu to 1.1.0 and fix extension realm visibility for JSR330 filtering - #12554

Open
gnodet wants to merge 3 commits into
masterfrom
fix/sisu-1.1.0-realm-visibility
Open

Bump Sisu to 1.1.0 and fix extension realm visibility for JSR330 filtering#12554
gnodet wants to merge 3 commits into
masterfrom
fix/sisu-1.1.0-realm-visibility

Conversation

@gnodet

@gnodet gnodet commented Jul 27, 2026

Copy link
Copy Markdown
Contributor

Summary

Root Cause

Sisu 1.1.0 introduces jsr330ComponentVisibilityFollowsPlexusVisibility (on by default), which filters beans based on ClassRealm visibility via RealmManager.computeVisibleNames(). This BFS traversal walks parent and import realms from the current TCCL.

The problem: Extension realms have plexus.core as their parent, but beans discovered in the container are sourced from the maven.ext realm. Since extension realms had no import relationship to maven.ext, the BFS traversal from an extension realm produces {extension_realm, plexus.core} — missing maven.ext entirely.

When it breaks: During lifecycle callbacks (e.g., Mimir extension), DefaultMaven.callListeners() sets TCCL to the extension's ClassRealm. If the callback triggers a Sisu dynamic map access (like Map<String, NameMapper>.get()), FilteredBeans evaluates the visibility predicate with the extension realm as context, finds maven.ext unreachable, and filters out all container-sourced beans → IllegalArgumentException: Unknown NameMapper name.

Fix

Adds a reverse import from each extension realm to the container realm (maven.ext), using the same importFrom(realm, realm.getId()) pattern already used for the forward direction. This makes maven.ext reachable in Sisu's visibility BFS, so container-sourced beans remain visible when TCCL is an extension realm.

This works with Sisu 1.1.0's filtering feature (not against it) — the realm visibility graph is corrected to reflect the actual relationship between extension and container realms.

Verified

  • ✅ Full mvn verify passes with Sisu 1.1.0 (595+ tests, 0 failures)
  • ✅ Build succeeds with Mimir extension (~/.m2/extensions.xml)
  • ✅ Mimir lifecycle callbacks work correctly (no NameMapper errors)

Test plan

  • mvn verify -Dversion.sisu-maven-plugin=1.1.0 passes locally
  • Build test project with Mimir extension enabled — BUILD SUCCESS
  • CI build passes

🤖 Generated with Claude Code

…ering

Sisu 1.1.0 adds JSR330 bean visibility filtering based on ClassRealm
hierarchy (jsr330ComponentVisibilityFollowsPlexusVisibility, on by default).
When TCCL is an extension realm during lifecycle callbacks, Sisu's
FilteredBeans calls RealmManager.computeVisibleNames() which traverses
parent and import realms via BFS. Extension realms have plexus.core as
parent but beans discovered in the container are sourced from the
maven.ext realm. Since extension realms had no import relationship
to maven.ext, container-sourced beans were incorrectly filtered out.

This caused failures with extensions like Mimir that register lifecycle
listeners: when the listener's callback triggered a Sisu dynamic map
access (e.g., NameMapper resolution), the beans were invisible from
the extension's realm, resulting in "Unknown NameMapper name" errors.

The fix adds a reverse import from each extension realm to the container
realm (maven.ext), following the same pattern already used for the
forward direction (maven.ext imports from extension realms). This
makes maven.ext reachable in Sisu's visibility BFS traversal, so
container-sourced beans remain visible regardless of TCCL context.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@gnodet
gnodet requested a review from cstamas July 27, 2026 22:22
@gnodet
gnodet marked this pull request as ready for review July 27, 2026 22:29

@gnodet gnodet left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Minimal, well-targeted fix that correctly adds a reverse ClassRealm import so Sisu 1.1.0's BFS-based visibility filtering can reach container-sourced beans from extension realms. Version bump is consistent and CI is fully green.

Key observations:

  • The unconditional placement of realm.importFrom(extRealm, extRealm.getId()) outside the if (exportedPackages.isEmpty()) guard is correct — the reverse direction must be wholesale so every extension realm gets container bean visibility regardless of its export configuration.
  • This PR supersedes open PRs #12551 and #12552 (plain Sisu version bumps without the realm fix). Those should be closed once this merges.

Minor note (non-blocking): The deprecated compat MavenCli.setupContainerRealm has the same realm setup pattern but does not receive the reverse import fix. If any consumer still enters Maven through this compat path with core extensions loaded, they would hit the same Sisu 1.1.0 FilteredBeans visibility failure. Worth confirming no active compat consumers rely on this path.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of gnodet

gnodet added a commit to gnodet/maven that referenced this pull request Jul 27, 2026
@gnodet gnodet added the dependencies Pull requests that update a dependency file label Jul 28, 2026
Regression test verifying that plugins NOT marked with
<extensions>true</extensions> do not cause build failures when they
ship JSR330 components whose internal dependencies cannot be resolved
in Maven's container. Uses tycho-bnd-plugin as the reproducer.

With Sisu 1.1.0's jsr330ComponentVisibilityFollowsPlexusVisibility,
non-extension plugin components are filtered out of container-realm
JSR330 lookups, preventing the provisioning error.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

@gnodet gnodet left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

New commit adds a regression integration test (MavenITgh12522NonExtensionPluginTest) verifying that non-extension plugins with JSR330 components don't cause build failures. Good addition — ensures this fix stays solid. Prior APPROVE still stands.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of gnodet

gnodet added a commit to gnodet/maven that referenced this pull request Jul 28, 2026
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant