When using Log4j2 in Intellij for a groovy/gradle project, log shows up red as if the injection is not working. Gradle runs and builds but every file in IntelliJ shows errors which is annoying.
dependencies
compile 'org.codehaus.groovy:groovy-all:2.4.4'
compile 'org.apache.logging.log4j:log4j-api:2.5'
compile 'org.apache.logging.log4j:log4j-core:2.5'
Source
import groovy.util.logging.Log4j2
#Log4j2
class TestLog4j2 {
public static void log(String message) {
log.error(message)
log from log.error is displayed in red and displays error, cannot resolve symbol 'log'
The log4j2.xml file is in the classpath and works.
#Log4j and even #Slf4j both work
Using IntelliJ 15.03 Build IU-143.1821
Project is using Groovy 2.4.4 and Gradle 2.3
Thoughts anyone?
I was getting this error when using groovy's #Log4j2 annotation.
The solution was to exclude the following module in gradle:
configurations.all {
exclude module: 'log4j-to-slf4j'
}
Related
Recently I started getting bad class file during build in IntelliJ IDEA 2021.2.2 and MapStruct version 1.4.2.Final. Maven build is running fine. Does anyone have a clue? Thanks a lot!!
Intellij compiler logs:
DEBUG - s.incremental.java.JavaBuilder - java:ERROR:Internal error in the mapping processor: com.sun.tools.javac.jvm.ClassReader$BadClassFile: bad class file: Please remove or make sure it appears in the correct subdirectory of the classpath.
at com.sun.tools.javac.jvm.ClassReader.badClassFile(ClassReader.java:357)
at com.sun.tools.javac.jvm.ClassReader.readEnclosingMethodAttr(ClassReader.java:1276)
at com.sun.tools.javac.jvm.ClassReader$12.read(ClassReader.java:1130)
at com.sun.tools.javac.jvm.ClassReader.readAttrs(ClassReader.java:1381)
at com.sun.tools.javac.jvm.ClassReader.readClassAttrs(ClassReader.java:1396)
at com.sun.tools.javac.jvm.ClassReader.readClass(ClassReader.java:2226)
at com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2324)
at com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:2511)
at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:2442)
at com.sun.tools.javac.jvm.ClassReader.access$000(ClassReader.java:76)
at com.sun.tools.javac.jvm.ClassReader$1.complete(ClassReader.java:240)
at com.sun.tools.javac.code.Symbol.complete(Symbol.java:574)
at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1037)
at com.sun.tools.javac.code.Symbol$ClassSymbol.flags(Symbol.java:973)
at com.sun.tools.javac.code.Symbol$TypeSymbol.getEnclosedElements(Symbol.java:734)
at javax.lang.model.util.ElementScanner6.visitPackage(ElementScanner6.java:167)
at com.sun.tools.javac.code.Symbol$PackageSymbol.accept(Symbol.java:901)
at com.sun.tools.javac.processing.JavacRoundEnvironment$AnnotationSetScanner.scan(JavacRoundEnvironment.java:158)
at com.sun.tools.javac.processing.JavacRoundEnvironment$AnnotationSetScanner.scan(JavacRoundEnvironment.java:127)
at com.sun.tools.javac.processing.JavacRoundEnvironment.getElementsAnnotatedWith(JavacRoundEnvironment.java:121)
at org.mapstruct.ap.MappingProcessor.getMappers(MappingProcessor.java:235)
at org.mapstruct.ap.MappingProcessor.process(MappingProcessor.java:165)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:802)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:713)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1800(JavacProcessingEnvironment.java:91)
at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1043)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1184)
at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1170)
at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856)
I have a Gradle plugin implemented with Kotlin, which is built with a gradle kotlin DSL build script. This works fine. The build script is as follows and is located in the buildSrc directory of project:
plugins {
groovy
`kotlin-dsl`
}
repositories {
mavenLocal()
mavenCentral()
jcenter()
}
dependencies {
testImplementation(gradleTestKit())
implementation(kotlin("gradle-plugin"))
implementation ("com.bmuschko:gradle-docker-plugin:6.1.3")
}
Now i want to call a existing Groovy Class in the same buildSrc Source Tree from the Kotlin Plugin code. This works fine in Intellij.
But when building with gradle i get a : unresolved reference Class for the Groovy Class.
Looking at the build, i see that the compileKotlin task is executed first. When i uncomment the failing reference, i see that the groovyCompile produces the correct binaries.
So i tried this:
tasks.compileKotlin {
dependsOn(tasks.compileGroovy)
}
Naturally that is not good enough, but i tried to get the build to compile the Groovy code first.
I got the following error:
Circular dependency between the following tasks:
:buildSrc:compileGroovy
\--- :buildSrc:compileJava
\--- :buildSrc:compileKotlin
\--- :buildSrc:compileGroovy (*)
So i tried without succeeding , to remove the compileJava task dependency from compileGroovy:
tasks.compileGroovy {
dependsOn.remove(tasks.compileJava)
}
Some problem as above. Basically it is unclear to me how to remove precondigured taskdependencies in gradle
What i really need is something equivalent to gradle groovy build as :
compileGroovy.dependsOn = compileGroovy.taskDependencies.values - 'compileJava'
compileKotlin.dependsOn compileGroovy
compileKotlin.classpath += files(compileGroovy.destinationDir)
classes.dependsOn compileKotlin
How would look that like the Gradle Kotlin Dsl?
Or are there better ways to solve this Groovy / Kotlin Code Dependency problem?
Version Info:
------------------------------------------------------------
Gradle 5.2.1
------------------------------------------------------------
Build time: 2019-02-08 19:00:10 UTC
Revision: f02764e074c32ee8851a4e1877dd1fea8ffb7183
Kotlin DSL: 1.1.3
Kotlin: 1.3.20
Groovy: 2.5.4
Ant: Apache Ant(TM) version 1.9.13 compiled on July 10 2018
JVM: 1.8.0_232 (AdoptOpenJDK 25.232-b09)
OS: Mac OS X 10.15.3 x86_64
I think this is equivalent, though I think it just knocks Java out of the picture, so Groovy/Kotlin/Java buildSrc code won't work...:
tasks {
val compileJava = named("compileJava", JavaCompile::class).get()
val compileKotlin = named("compileKotlin", KotlinCompile::class).get()
val compileGroovy = named("compileGroovy", GroovyCompile::class).get()
val classes by getting
compileGroovy.dependsOn.remove("compileJava")
compileKotlin.setDependsOn(mutableListOf(compileGroovy))
compileKotlin.classpath += files(compileGroovy.destinationDir)
classes.setDependsOn(mutableListOf(compileKotlin))
}
This has been vastly improved in Gradle 6.1
https://docs.gradle.org/6.1/release-notes.html#defining-compilation-order-between-groovy,-scala-and-java
And I'm not sure the above works for test ordering if they have unexpected language dependency ordering
I am trying to use the new Predator JPA/JDBC library from Micronaut.
I wish to use the JDBC integration rather than JPA.
I am having a couple of issues however, the documentation says to include:
annotationProcessor 'io.micronaut.data:micronaut-predator-processor:1.0.0.BUILD-SNAPSHOT'
Which I have done so, but the kapt section of the build fails with the following error:
Caused by: java.lang.NoSuchMethodError: io.micronaut.core.annotation.AnnotationMetadata.enumValue(Ljava/lang/Class;Ljava/lang/String;Ljava/lang/Class;)Ljava/util/Optional;
I am using micronaut 1.1.4 on JVM 12.0.1
If I replace kapt with annotationProcessor, the build completes fine, however I get a runtime issue:
Caused by: java.lang.ClassNotFoundException: io.micronaut.data.exceptions.DataAccessException
Which is odd as I seem to be able to use kapt/annotationProcessor interchangeable for micronaut security.
I faced the same problem when running tests from Intellij Idea. But they passed when run through gradle.
If you are using Intellij Idea and facing this issue, try following options in the sequence:
Invalidate Idea cache and restart
Enable Annotation Processing
Delegate IDE build/run actions to gradle. This setting had got reset to Idea when I upgraded my Intellij version.
I can get this to work for the micronaut 1.2.0 RC2 by updating the BOM entry:
dependencyManagement {
imports {
mavenBom 'io.micronaut:micronaut-bom:1.2.0.RC2'
}
}
This seems to allow all the annotation processing etc to work correctly.
I have a simple build script (shorted for clarity) which uses Guava as a dependency
group 'test'
version '0.1.0'
apply plugin: 'java'
apply plugin: 'application'
sourceCompatibility = 1.8
targetCompatibility = 1.8
mainClassName = 'Test'
repositories {mavenCentral()}
task wrapper(type: Wrapper) {gradleVersion = '3.5'}
dependencies {compile 'com.google.guava:guava:21.0'}
When running this code:
public class Test {
public static void main(String[] args) {
LoadingCache<Long, String> applicantCache = CacheBuilder.newBuilder()
.maximumSize(30000)
.expireAfterAccess(31, TimeUnit.DAYS)
.build(new CacheLoader<Long, String>() {
#Override
public String load(Long key) {
return "";
}
});
}
}
I get this error:
java.lang.NoClassDefFoundError: com/google/common/cache/CacheLoader
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
at java.lang.Class.getMethod0(Class.java:3018)
at java.lang.Class.getMethod(Class.java:1784)
at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)
Caused by: java.lang.ClassNotFoundException: com.google.common.cache.CacheLoader
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 7 more
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main"
When downgrading the Gradle Wrapper version to 3.3 the problem is fixed but, I need version 3.5 for something else that is not feasible in version 3.3. As far as I can understand there is some dependency conflict between this version of Gradle and Guava but according to this post - it is not possible.
I know the jar is in place + using gradle dependencyInsight --dependency com.google.guava shows that the dependency exists:
:dependencyInsight
com.google.guava:guava:21.0
\--- compile
Thanks for any help
EDIT:
After testing on other computers it seems the problem only occurs when I update the wrapper task, execute it and then refresh the gradle project by clicking on the Refresh all Gradle projects button (see attached image). When running the executing distribution script every thing works fine - so it only happens in Intellij. I'm guessing I'm missing something in how Gradle Wrapper works or when to execute it...
EDIT
Tested on Gradle version 3.4 and the problem occurres.
if anyone else encounters similar issues the answer is here.
A bug in my Intellij version (2016.2.5) caused compile scoped dependencies to transform into provided scoped dependencies by Intellij. This, in turn, makes dependencies to appear only in Intellij's compile classpath but not in it's runtime classpath. That's why when running the ./gradlew run command the issue could not be reproduced as there was no issue on Gradle's part.
Upgrading the Intellij version (2017.1) solved the issue.
Trying to run my eclipse plugin from within eclipse, I get error messages to the console, which make the nested eclipse fail to run the plugin:
org.osgi.framework.BundleException: Error starting module.
at org.eclipse.osgi.container.Module.doStart(Module.java:590)
...
Caused by: java.lang.Error: Unresolved compilation problems:
The import org.eclipse cannot be resolved
The import org.eclipse cannot be resolved
The import org.eclipse cannot be resolved
The import org.eclipse cannot be resolved
The import org.osgi cannot be resolved
AbstractUIPlugin cannot be resolved to a type
IStartup cannot be resolved to a type
The method earlyStartup() of type Plugin must override or implement a supertype method
BundleContext cannot be resolved to a type
BundleContext cannot be resolved to a type
Suggesting that my plugin has compilation errors to it, but:
The plugin has not compilation errors
It seems a bit surprising that running a plugin would cause a compilation.
There was indeed no compilation error: the problem lies elsewhere. The main
Plugin class was to be a singleton, which was implemented like so:
public class Plugin extends AbstractUIPlugin implements IStartup {
public static Plugin plugin;
/ ** an empty c'tor. creates an instance of the plugin. */
public Plugin() {
plugin = this;
}
....
}
Now, other classes were referring to this public field, which not initialized; for some reason, eclipse thought this was a compilation
error. It was not. using a getter for that field solved the problem.