You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "wilx (via GitHub)" <gi...@apache.org> on 2026/09/20 13:26:26 UTC
[PR] Expose Maven logging output capabilities in Maven 4.1 [maven]
wilx opened a new pull request, #13208:
URL: https://github.com/apache/maven/pull/13208
Plugins currently have to inspect logging internals to learn where Maven writes and which charset it uses. Add an injectable `OutputCapabilities` service plus an immutable `maven.logging.outputCapabilities` map in execution-request data for plugins compiled against older Maven APIs.
Capture the actual logging route, report uncertain detection as `UNKNOWN`, and preserve resident-invocation cleanup without changing output routing or encoding.
Validation: reactor verification (excluding existing IDE `.iml` files), focused Core ITs, and Linux runtime checks passed. macOS and Windows remain untested.
- [x] I license this contribution under the [Apache License 2.0](https://www.apache.org/licenses/LICENSE-2.0).
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Expose Maven logging output capabilities in Maven 4.1 [maven]
Posted by "gnodet (via GitHub)" <gi...@apache.org>.
gnodet commented on PR #13208:
URL: https://github.com/apache/maven/pull/13208#issuecomment-6060241844
Good idea — moving `OutputCapabilities` into the Maven 4 API layer would make it a proper first-class service accessible via `session.getService(OutputCapabilities.class)`.
A few things to think through before committing to this direction:
**What moves where**
- `OutputCapabilities` interface + `Destination` enum → `api/maven-api-core`, package `org.apache.maven.api.services`, implements `Service` (required for `Session.getService()`)
- `DefaultOutputCapabilities` (the mutable singleton with `install()`/cleanup) → `impl/maven-impl`, package `org.apache.maven.impl`, annotated `@Named @Singleton @Priority(-1)` — this is the fallback that returns `UNKNOWN` in embedded contexts
- `TerminalOutputCapabilities` (JLine probe logic) → stays in `impl/maven-cli` — it depends on `FastTerminal`, `TerminalExt`, `ExecTerminalProvider`, which are JLine internals; moving them closer to the API would leak JLine into `maven-impl`
- A higher-priority CLI override in `impl/maven-cli` or `impl/maven-jline` wires the actual terminal probe into the service — same pattern as `DefaultMessageBuilderFactory` (`@Priority(-1)` in `maven-impl`) overridden by `JLineMessageBuilderFactory` (`@Priority(10)` in `maven-jline`)
**The `install()`/cleanup problem**
The current design has `DefaultOutputCapabilities.install()` return an `AutoCloseable` that is added to `LookupContext.closeables` — this is how it resets to `UNKNOWN` between resident invocations. If `DefaultOutputCapabilities` lives in `maven-impl` and is a pure `Service`, the install/cleanup contract becomes internal CLI plumbing — the API interface exposes only `getDestination()` / `getEncoding()`, and the mutation lives in a `DefaultOutputCapabilities` cast. That's the same pattern the current PR uses; it just changes which module owns the default impl.
Alternatively: ditch the `install()`/resident cleanup entirely and make the service read from a thread-local or a `@Named("outputCapabilities") Supplier<…>` provided by the CLI invoker. Cleaner separation, but a bigger refactor.
**The `@Experimental` annotation**
Since this is genuinely new API surface and detection is inherently best-effort (especially the `ExecTerminalProvider` inconclusive-negative case), `@Experimental` on the interface is important. Worth noting explicitly.
**Impact on the logging PR chain**
As noted in the earlier review, this PR needs a rebase on `feature/console-modes` (#13180) regardless. Once there, `determineConsoleMode()` should feed directly into the capabilities supplier — `CONSOLE` / `REDIRECTED` / `FILE` can be decided from the console mode + `-l` flag without touching JLine at all in most cases; the JLine probe is only the fallback when no explicit `--console` flag was given.
Summary: the direction is the right one — `maven-api-core` interface + `maven-impl` default + CLI override. The main decision point is whether to keep the `install()`/cleanup pattern (mutable singleton) or replace it with a `Supplier` injected by the CLI layer. Happy to look at either approach.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Expose Maven logging output capabilities in Maven 4.1 [maven]
Posted by "gnodet (via GitHub)" <gi...@apache.org>.
gnodet commented on PR #13208:
URL: https://github.com/apache/maven/pull/13208#issuecomment-5761535640
I closed https://github.com/apache/maven/pull/13209, https://github.com/apache/maven/pull/13210 as I don't think we should back port those.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Expose Maven logging output capabilities in Maven 4.1 [maven]
Posted by "wilx (via GitHub)" <gi...@apache.org>.
wilx commented on PR #13208:
URL: https://github.com/apache/maven/pull/13208#issuecomment-6067236836
I have rebased this PR onto #13180 and moved the API and implementations into the suggested modules.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Expose Maven logging output capabilities in Maven 4.1 [maven]
Posted by "gnodet (via GitHub)" <gi...@apache.org>.
gnodet commented on PR #13208:
URL: https://github.com/apache/maven/pull/13208#issuecomment-5750812228
Thanks for this contribution — the use case is real and the API design (`OutputCapabilities` as an injectable service with a fallback `Map<String, String>` in request data for older-API plugins) is clean.
A few thoughts before this can move forward:
**Milestone / branch targeting**
This PR targets `master` (4.1.0), which is the right vehicle. However, the integration points it touches — `LookupInvoker`, `LookupContext`, and `PlexusContainerCapsule.updateLogging()` — are actively being reshaped by the logging feature chain currently under review (#12694, #13180, and related PRs). This PR will need to be rebased on top of `feature/console-modes` (#13180) before it can be cleanly reviewed, as the context initialization path is changing there.
**Interaction with `--console=machine`**
When `--console=machine` is active (#13180), Maven writes JSON lines to stdout rather than using the terminal for human-readable output. In that case, `Destination` should be deterministically `REDIRECTED` (or a new `MACHINE` value) derived directly from the console mode flag, not from JLine terminal introspection. Right now `TerminalOutputCapabilities.destination()` will likely give the right answer incidentally (dumb terminal → `REDIRECTED`), but it's fragile — if the stdout routing ever changes in machine mode, the detection would silently regress. Once rebased on `feature/console-modes`, the `MavenInvoker.determineConsoleMode()` result should feed directly into the `outputCapabilities` supplier in `LookupContext`.
**Backports (#13209, #13210)**
I'd recommend keeping the 3.10.x and 4.0.x backports as drafts for now. This is new API surface, not a bug fix, and adding a new injectable service to maintenance branches is invasive. If `dependency:tree` or other tools have a concrete regression to fix, that's a different conversation — but the general feature belongs in 4.1.0.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Expose Maven logging output capabilities in Maven 4.1 [maven]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on PR #13208:
URL: https://github.com/apache/maven/pull/13208#issuecomment-6059101548
<!-- license-declaration-check -->
### ⚠️ License declaration missing
The pull request description must contain at least one of the following lines with a **checked** box (`[x]`):
```markdown
- [ ] I hereby declare this contribution to be licensed under the [Apache License Version 2.0, January 2004](https://www.apache.org/licenses/LICENSE-2.0)
- [ ] I hereby declare that I have filed an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf).
```
This comment will be hidden automatically once the description is fixed.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org