[
https://issues.apache.org/jira/browse/LOG4J2-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16701156#comment-16701156
]
Ralph Goers edited comment on LOG4J2-2516 at 11/27/18 11:17 PM:
----------------------------------------------------------------
I've read the threads and it appears the Gradle folks have decided they don't
like the way Javac was implemented and decided to "fix" it. My guess is they
are defining a bogus processor path to prevent Javac from looking for
annotation processors on the classpath. Their proposed solution seems to be
that you have to remove the annotation processor from your jar and make it be a
separate jar. This would mean anyone developing plugins for Log4j would have
to specifically add the annotation processor to their build.
I noticed a few queries to other projects that I didn't see a reply to.
Notably, one for Spring Boot. I would wonder about that since Spring uses
Gradle as its build tool.
I will say that this is the first report we have had about this problem. This
issue was brought to the Gradle team's attention in April yet no one there
thought to mention it to us?
I am not sure how simple it will be to separate out the annotation processor.
It may be very easy or very hard. I am not even sure if it is something the
team wants to do since it was intentionally placed on the classpath when it was
developed.
was (Author: [email protected]):
I've read the threads and it appears the Gradle folks have decided they don't
like the way Javac was implemented and decided to "fix" it. My guess is they
are defining a bogus processor path to prevent Javac from looking for
annotation processors on the classpath. Their proposed solution seems to be
that you have to remove the annotation processor from your jar and make it be a
separate jar. This would mean anyone developing plugins for Log4j would have
to specifically add the annotation processor to their build.
I noticed a few queries to other projects that I didn't see a reply to.
Notably, one for Spring Boot. I would wonder about that since Spring uses
Gradle as its build tool.
I will say that this is the first report we have had about this problem. This
issue was brought to the Gradle team's attention in April yet no one there
thought to mention it to us?
I am not sure how simple it will be to separate out the annotation processor.
It may be very easy or very hard.
> log4j2 incompatible with Gradle 5.0
> -----------------------------------
>
> Key: LOG4J2-2516
> URL: https://issues.apache.org/jira/browse/LOG4J2-2516
> Project: Log4j 2
> Issue Type: Bug
> Affects Versions: 2.11.1
> Reporter: Martin Schröder
> Priority: Major
>
> Log4j2 can not be used with the recently released Gradle 5.0 because
> {quote}Deprecated Gradle features were used in this build, making it
> incompatible with Gradle 5.0.
> {quote}
> {quote}Putting annotation processors on the compile classpath has been
> deprecated and is scheduled to be removed in Gradle 5.0. Please add them to
> the processor path instead. If these processors were unintentionally leaked
> on the compile classpath, use the -proc:none compiler option to ignore them..
> {quote}
> And yes, support for annotation processors has been removed in 5.0.
> Discussions of these problems are
> [here|https://discuss.gradle.org/t/regarding-the-annotation-processors-on-compile-classpath-warning-in-gradle-4-6/26144/2]
> and [here|https://github.com/gradle/gradle/issues/5056]; please refer to
> them for more information. I'm _not_ an expert on this issue, merely a user
> of both Log4J2 and Gradle.
> While Gradle has issued these warnings since at least 4.6, I did not find a
> discussion about this in the log4j2 bug tracker (and the issue has not been
> fixed yet).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
