gnodet opened a new issue, #13805: URL: https://github.com/apache/maven/issues/13805
## Problem Currently, `Listener` (and its subtypes `ExecutionListener`, `RepositoryListener`) must be registered programmatically via `Session.registerListener()`. This requires the caller to already have a live `Session` instance, which means core extensions loaded at startup via `META-INF/services/` have no way to register themselves as listeners — they have no `Session` yet when they are instantiated. ## Proposal Auto-discover `Listener` implementations that also implement `SpiService`: during session initialization, Maven would iterate the already-discovered `SpiService` instances, filter those that are `instanceof Listener`, and call `session.registerListener()` on each automatically. This requires **no interface inheritance** between `Listener` and `SpiService` (which would create a circular module dependency since `maven-api-spi` depends on `maven-api-core`). The two interfaces remain independent; the convention is purely in Maven's bootstrap wiring. ### What this enables A core extension in `maven-api-spi` could implement both `SpiService` and `ExecutionListener` (or `RepositoryListener`) and receive typed event callbacks without any explicit registration, simply by being declared in `META-INF/services/`. ### What this does not change - `Listener` stays in `maven-api-core`, `SpiService` stays in `maven-api-spi` — no module restructuring needed. - Programmatic `session.registerListener()` continues to work as before. - No new interface hierarchy is introduced. ## Context This came up during review of #13647 (Maven 4 lifecycle participation SPI). The `LifecycleParticipant` SPI introduced there extends `SpiService` directly and uses its own dispatcher, which duplicates what the `Listener` dispatch infrastructure already provides for execution-phase callbacks. Auto-discovering `Listener`+`SpiService` implementations would allow that SPI to compose cleanly with the existing event system. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
