Factor pluggable modules out of `runtime/service`

[dimas-b]

This is a proposal to refactor inter-module dependencies in order to allow easier selection of pluggable features in downstream builds.

• Move pluggable (optional) module dependencies out of runtime/services into runtime/server
• Move the majority of integration tests into new sub-modules under the pluggable components
  • Example: persistence/relational-jdbc/tests
  • Prior art: extensions/auth/opa/tests
• Run "smoke tests" for the default set of plugins under the runtime/server module (e.g. validating PostgreSQL integration, but without extensive code coverage, which will be done under persistence/relational-jdbc/tests).

The functionality provided by the runtime/server module will not be altered by this change.

Pros:

• It will be easier to select a sub-set of optional features to include in downstream builds (some of which may not need all of the pluggable features)
• The runtime/service module becomes lean and focused on Polaris fundamentals.

Cons:

• CI time may increase due to having to perform more Quarkus builds for integration tests (might be mitigated by parallel execution).

[tiru-venkatesh]

This makes sense from a modularity and downstream-consumption perspective.

I especially like the idea of isolating integration tests closer to their respective pluggable components while keeping runtime/server focused on smoke coverage.

I’ll follow the discussion here — happy to help review or test incremental changes once there’s agreement on the refactoring approach.

[adutra]

Does this proposal also includes splitting the runtime/service module itself into smaller components by area/topic (authn, authz, otel, etc.)?

[tiru-venkatesh]

From my reading, I understood the proposal as primarily focusing on moving pluggable/optional dependencies and their integration tests out of runtime/service, rather than restructuring runtime/service itself by functional areas.

That said, I’ll defer to @dimas-b on intended scope and whether further internal decomposition is in consideration or intentionally out of scope for this proposal.

[dimas-b]

@adutra : While I did not intend to further split runtime/service into smaller modules under this PR, I would not mind that.

Smaller modules will be beneficial to downstream projects in allowing them to reduce the amount of dependent code according to their requirements.

[dimas-b]

Related PR: #3601

[tiru-venkatesh]

That makes sense 👍

Smaller, topic-oriented modules inside runtime/service (authn, authz, otel, persistence wiring, etc.) would nicely complement the original goal of isolating pluggable dependencies.

One potential advantage I see is that downstream builds could depend on a minimal “core” runtime surface while selectively pulling in only the service capabilities they need, without inheriting transitive optional features.

If this direction is explored, it might be worth defining clear boundaries between:

core runtime fundamentals

service-level abstractions

pluggable integrations + their test modules

Happy to help review or experiment with an incremental split once there’s agreement on scope and boundaries.