Vampire commented on issue #4034: URL: https://github.com/apache/logging-log4j2/issues/4034#issuecomment-3909004587
I'm not sure what you mean by "pushing fixes for annotation dependencies to every single release in the last 2 years or so". Maven Central artifacts are not mutable afair, are they? Also, in releases before 2.25 this was fine as no GMM was published and the POM does not have this. It was added in afa773a1ff2c9e773dd8e0745eead24b9c3ec32a by a PR from @jjohannes to have these dependencies added by publishing the GMM with them. But doing so is imho horribly wrong and just working around a problem in consumers that they have self-made by using `-Werror` for the Java compiler and thus hitting the JVM bug that is the actual problem here. If one does not use `-Werror` one does not have a problem. If one does use `-Werror` and thus hits the JVM bug mentioned above, then imho where you do the `-Werror` you should also do the work-around by adding the annotation libraries to the compile classpath and stress the JVM development to fix that bug. In my opinion it is the wrong way for a library to add the annotation libraries to consumer compile classpaths to work-around a JVM bug that only some users are hitting due to their compiler settings and at the same time polluting the compile classpath of all consumers needlessly that do not have such a configuration. And even if you want to do this imho wrong work-around on log4j side, it should at least be restricted to the actual artifacts that use those annotations and not to all artifacts like it is right now. It makes absolutely no sense to have those dependencies for `log4j-api` for example as that artifact does not use any of those annotation dependencies. > I'd support such a direction. Would you mind contributing this change in a PR, please? Unfortunately, I don't touch Maven with a five-foot pole if I can avoid it, and here this is a Maven build with some plugin that builds the GMM file for publication, and I wouldn't even know how to test this locally, as an `install` does not even put the GMM to the Maven Local repository (which is probably also a bug but in that plugin I guess). Maybe @jjohannes can clean this up to at least only contain this disruptive dependencies on the relevant artifacts that should imho be completely removed, as he also made the PR that added them to each and every artifact if you really prefer to keep this work-around that pollutes the compile classpath of most of your consumers needlessly. -- 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]
