ppkarwasz commented on issue #3779:
URL:
https://github.com/apache/logging-log4j2/issues/3779#issuecomment-3239986567
> I don't believe this to be accurate. I don't think this is about silencing
an ERROR log, but rather to fix an invalid POM. I've used the dependency
resolver of the Maven project against `org.apache.logging.log4j:log4j:2.25.1`
and this is what I got:
>
> ```
> 20:34:53.015 [main] WARN i.s.p.s.r.m.DefaultDependencyResolver - Model
for 'org.apache.logging.log4j:log4j:2.25.1:pom' is incomplete:
> [[WARNING] 'build.plugins.plugin.version' for
org.codehaus.gmavenplus:gmavenplus-plugin is missing. @
org.apache.logging.log4j:log4j:2.25.1,
/Users/snicoll/workspace/work/projects-support/projects-support/build/repo-test/org/apache/logging/log4j/log4j/2.25.1/log4j-2.25.1.pom,
> [WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-clean-plugin is missing. @
org.apache.logging.log4j:log4j:2.25.1,
/Users/snicoll/workspace/work/projects-support/projects-support/build/repo-test/org/apache/logging/log4j/log4j/2.25.1/log4j-2.25.1.pom,
> [WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-enforcer-plugin is missing. @
org.apache.logging.log4j:log4j:2.25.1,
/Users/snicoll/workspace/work/projects-support/projects-support/build/repo-test/org/apache/logging/log4j/log4j/2.25.1/log4j-2.25.1.pom,
> [ERROR] 'dependencies.dependency.version' for
com.google.errorprone:error_prone_annotations:jar must be a valid version but
is '${error-prone.version}'. @ org.apache.logging.log4j:log4j:2.25.1,
/Users/snicoll/workspace/work/projects-support/projects-support/build/repo-test/org/apache/logging/log4j/log4j/2.25.1/log4j-2.25.1.pom]
> ```
You’re right:
* The published POM fails Maven’s `ModelValidator` and throws during
effective-model building: we’ll fix that.
* In practice, most resolvers (including your Gradle integration) catch the
exception and continue, so dependency resolution still succeeds.
* The problematic coordinate is in the `provided` scope, so it isn’t
consumed by downstream users. In practice, the effect is _cosmetic noise_, not
a functional break.
**Note.** Since `2.25.0` we also publish Gradle Module Metadata (`.module`)
alongside the POM: e.g.
[`log4j-api-2.25.0.module`](https://repo.maven.apache.org/maven2/org/apache/logging/log4j/log4j-api/2.25.0/log4j-api-2.25.0.module).
You might consider using this file, which is **self-contained** and encodes
the exact variants/dependencies without POM property interpolation, so Gradle
consumers won’t hit this POM-specific validation noise.
> As for creating upgrade churn, we had our fair share of that trying to
upgrade to Log4J 2.25 so I'd really hope we could put this behind us and not
have to do that + whatever is coming at us for 2.26.
Sorry for the friction with 2.25. From what we’ve seen, most of the pain
came from (a) deprecations in throwable converters and (b) GraalVM changes.
We’re acting on both:
* **Deprecations.** We’ll flag them earlier and louder (release notes,
migration notes, examples) so downstream changes aren’t a surprise.
* **GraalVM.** Since `2.25.1` (see #3755), no extra annotation-processor
flags are needed: Log4j now generates its own GraalVM metadata for himself and
your plugins. That should reduce maintenance on your side: for Logback and many
other libraries your team had to heavily contribute to the
[`graalvm-reachability-metadata`](https://github.com/oracle/graalvm-reachability-metadata)
repo.
For **2.26**, we’re still shaping the scope based on user feedback and don’t
want to rush it. We have an open proposal to simplify Spring Boot integration
(#3839) and would really value your input.
On cadence, our target for minors is \~3–6 months. If it helps Spring Boot,
we’re happy to line up our dates so you can take Log4j Core `2.26.0` and
`3.0.0` in Spring Boot 4.1.x.
More broadly, we’d like to re-establish a lightweight feedback loop. Over
the last couple of years we haven’t always managed to sync, even on areas where
we can help (structured logging, native image, JSON layouts, async). To keep
this easy:
* designate a point of contact on each side,
* tag us on Spring Boot PRs/issues that touch logging, and
* do a 30-minute check-in from time to time
If that works, we’ll adapt to your cadence. Given Spring Boot’s reach,
making integration and upgrades smooth directly serves the ASF mission of
“software for the public good.”
> I am out next week but we can coordinate for the week after unless someone
else on the team has time before that.
Sounds good: enjoy the time off. We’ll target a `2.25.2` RC on September
8th, so you can review it.
--
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]
