I'm trying to run the findbugsMain task in Gradle 1.10 (or more specific "gradlew check") but the only thing I get is an error like
building findbugsMain 33% > ...
:findbugsMain FAILED
It seems to download the required jars though:
...
Download http://repo1.maven.org/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar
Download http://repo1.maven.org/maven2/asm/asm/3.3/asm-3.3.jar
Download http://repo1.maven.org/maven2/asm/asm-tree/3.3/asm-tree-3.3.jar
Download http://repo1.maven.org/maven2/asm/asm-commons/3.3/asm-commons-3.3.jar
Download http://repo1.maven.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.jar
Download http://repo1.maven.org/maven2/jdom/jdom/1.0/jdom-1.0.jar
Download http://repo1.maven.org/maven2/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
Download http://repo1.maven.org/maven2/xom/xom/1.0/xom-1.0.jar
Download http://repo1.maven.org/maven2/xerces/xmlParserAPIs/2.6.2/xmlParserAPIs-2.6.2.jar
Download http://repo1.maven.org/maven2/xalan/xalan/2.6.0/xalan-2.6.0.jar
Download http://repo1.maven.org/maven2/com/ibm/icu/icu4j/2.6.1/icu4j-2.6.1.jar
:findbugsMain FAILED
I ran the task using --stacktravce again and this is what I got:
Pastebin link
My build.gradle is also on Pastebin
I'm relatively new to build management tools in general and gradle in particular, so it might be my fault (e.g. buildscript has an error).
Judging from the stack trace, some internal error occurs. This could be due to an incompatibility between the version of the ASM library used by Gradle, and the version expected by FindBugs. Would you mind to file an issue over at http://forums.gradle.org, ideally including a minimal reproducible example?
As it seems FindBugs up to version 2.0.3 has problems with some Java 8 classfiles. These
problems will be addressed in the next major version of FindBugs. Until then you have to use Java 7.
So, the short version is, that I changed the language level to 1.7 and everything runs just fine now.
Thanks #peter for the help.
Related
Installed clean windows10(1607) and intellij idea(2020.1.2 community edition). When i create new gradle project
Invalid Gradle JDK configuration found. Open Gradle Settings
"gradle-wrapper.properties not found".
How can I fix it?
Install gradle 6.7
sdk install gradle 6.7
brew install gradle
Go to IntelliJ and set gradle version:
On File >> Settings >> Build, Execution , Deployment >> Gradle
or
Preferences >> Gradle
In Use Gradke from specific the correct location
If IDEA is set to use the Gradle wrapper (as it is in your screenshot: "Use Gradle from:" is set to "gradle-wrapper.properties"), IDEA expects the following file structure:
Gradle wrapper JAR: [project root]/gradle/wrapper/gradle-wrapper.jar
Gradle wrapper properties: [project root]/gradle/wrapper/gradle-wrapper.properties
Gradle wrapper script: [project root]/gradlew.bat
If you are missing one of these three elements, IDEA will attempt to generate the wrapper by calling the gradle wrapper task. It will do this using the Gradle JDK, which may or may not be the project SDK (File > Settings > Build, Execution, Deployment > Build Tools > Gradle > Gradle JVM).
I'm not sure how it selects the version of Gradle it uses - I only have 6.8.3 installed on my machine, and I had my wrapper properties set to 7.0-rc-1, yet somehow it used 6.7.0 when generating the wrapper.
I tried various options for clearing the cache, but did not get the result.
Openjdk-14 installed by default and does not work. From site adoptopenjdk.net install OpenJDK 11 (LTS). When creating the project, I chose 11 version. Then the program suggested updating gradle to version 6 and it worked.
I ran into this problem a while ago when I upgraded to intellij 2020.* The first time I created a new project there was no problem: gradle daemon did its work and the project was created with no problems.
In my case, the project would start a new gradle daemon, and attempt to build the project, would get rejected by windows Security, and nothing would happen, so intellij goes ahead and starts another (unsuccessful) daemon. Soon, I had 20+ gradle daemon processes running on my system, all of them doing nothing.
So, it looks like intellij has messed in enabling that it places the appropriate permissions it requires for these folders that it depends on to run properly. So, you need to manually give these permissions, and then things (should) work.
The real issue here is security on your machine: either a virus checker or the security software, Windows Security on Windows 10, for example. The first time you make a project, Intellij goes and produces a number of folders that they need access to.
However, once these folders are available, for whatever, intellij doesn't make sure to give itself access.
On windows 10, in AppData, you'll find several folders required by Intellij to produce, in my case, produce gradle projects.
Try finding the various folders that Intellij has produced on your system, and give them exceptions on your virus checker and on whatever firewall/security software programs that may block access.
I'm new to Android development and keep running into this specific error when I try building my test app via the Windows command: python setup.py android -s:
Could not resolve all files for configuration ':debugCompileClasspath'
Could not find com.android.support:appcompat-v7:25.1.1.
So how do I resolve all files for configuration?
After several hours of troubleshooting, related answers to this question have not worked for me. For instance, I have tried manipulating my build.gradle file in the following manner:
Modified maven() to maven {url "https://maven.google.com" }
Modified jcenter() to jcenter { url "http://jcenter.bintray.com/" }
Moved jcenter... to be the last item in the list under repositories { .... (there is no allprojects { ... category)
Added buildToolsVersion "27.0.3" under android { ....
Modified the classpath version to the latest gradle version 3.1.0 like so classpath 'com.android.tools.build:gradle:3.1.0' (it was initially using an out of date version)
Updated Android Studio IDE
Uninstalled and reinstalled all SDK-tools under the SDK Manager
(Full build.gradle here, on pastebin)
The only remaining helpful hint I have here is the information provided by the log.
It tells me that it can't find files in directories on my hard drive. All other related outputs I've seen from others is the location specifiying actual websites related to google or gradle.
Could not resolve all files for configuration ':debugCompileClasspath'.
> Could not find com.android.support:appcompat-v7:25.1.1.
Searched in the following locations:
file:/C:/Users/USERNAME/AppData/Local/Android/sdk/extras/m2repository/com/android/support/appcompat-v7/25.1.1/appcompat-v7-25.1.1.pom
file:/C:/Users/USERNAME/AppData/Local/Android/sdk/extras/m2repository/com/android/support/appcompat-v7/25.1.1/appcompat-v7-25.1.1.jar
file:/C:/Users/USERNAME/AppData/Local/Android/sdk/extras/google/m2repository/com/android/support/appcompat-v7/25.1.1/appcompat-v7-25.1.1.pom
file:/C:/Users/USERNAME/AppData/Local/Android/sdk/extras/google/m2repository/com/android/support/appcompat-v7/25.1.1/appcompat-v7-25.1.1.jar
file:/C:/Users/USERNAME/AppData/Local/Android/sdk/extras/android/m2repository/com/android/support/appcompat-v7/25.1.1/appcompat-v7-25.1.1.pom
file:/C:/Users/USERNAME/AppData/Local/Android/sdk/extras/android/m2repository/com/android/support/appcompat-v7/25.1.1/appcompat-v7-25.1.1.jar
I also have this error, which may or may not contribute to the files not being in the specified directory:
Deprecated Gradle features were used in this build, making it incompatible with Gradle 5.0.
See https://docs.gradle.org/4.7/userguide/command_line_interface.html#sec:command_line_warnings
Can anyone help me troubleshoot this issue and essentially resolve all files for configuration so that I can run my test app? Any help is greatly appreciated. Feel free to let me know if there's any additional I can provide.
We are facing a strange problem. We are using net.ltgt.errorprone, version (0.0.8), along with guava(version 21) and gradle(version 3.1). Everything was working fine till today's morning. But suddenly all developers started getting this error
[system.err] An exception has occurred in the compiler (1.8.0_162). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program and the following diagnostic in your report. Thank you.
java.lang.NoSuchMethodError: com.google.common.base.Verify.verify(ZLjava/lang/String;Ljava/lang/Object;)V
at com.google.errorprone.ErrorProneAnalyzer.finished(ErrorProneAnalyzer.java:132)
We searched through internet, most of the solutions are related to guava, but there was no change in guava version or
errorprone or gradle since a long time. We tried running old code also, getting the same error. We are unable to understand root cause of the problem. Did anyone face the same problem?
com.google.collections:google-collections was renamed to com.google.guava:guava which is really annoying and can often lead to two versions of the library on the classpath.
Here's how I'd diagnose the problem
Run gradle dependencies in the "broken" build
Go back in history in source control (git?) until you have a working version
Run gradle dependencies in the "working" build
Look for differences in versions of com.google.collections:google-collections
Look for differences in versions of com.google.guava:guava
See here in the Gradle docs where guava rename is discussed
You might need to add this to build.gradle
dependencies {
modules {
module("com.google.collections:google-collections") {
replacedBy("com.google.guava:guava", "google-collections is now part of Guava")
}
}
}
A new version(2.3.0) of errorprone was released, this broke our build.
We find out the dependency using this command
./gradlew -q dependencyInsight --configuration errorprone --dependency error_prone_core
This clearly showed that latest version is being used. We fixed it by using a last workable version forcefully. Following lines were added to build.gradle file
configurations.all {
resolutionStrategy {
force 'com.google.errorprone:error_prone_core:2.2.0'
}
}
I'm using IntellJ 14.1.4 Community Edition
My project compiled fine before (I have it set up to use the Eclipse compiler)
But I tried to Mavenize it...
I added Maven via the Add Framework | Maven command
Now my problem is (still using the Eclipse Compiler)...
It gives me error messages like:
Error:(21, 78) java: '<>' operator is not allowed for source level below 1.7
Which leads me to suspect that it is not compiling to 1.8
However, I didn't change anything other than Mavenizing it
The Project SDK in IDEA is set to use 1.8
I did notice some setting about bytecode being 1.5.. but i tried to change that to 1.8 but still get this error message.
Anyone have any clue what's going on?
this was essentially the correct advice of course - in the comments, however I had been trying to do it for a long time both via maven-compiler-plugin and properties... to no success, even though I was refreshing Maven after making changes to pom.xml. Finally, I restarted the IDE .. and .. it works! I can compile..
We would like to have a script that does "svn update" and if the depedency.gradle file is in that list of updates, we would like to run a task that ONLY updates dependencies so the developers machine is up to date. What would that task be? I don't see it when running "gradle tasks". Looking for an updatejars or something.
When we build our project, we don't want it to check for jar updates at all!!!! most because that only needs to be done in 2 situations which are #1 above and when someone is updating the dependency.gradle file themselves. For the second thing, they can just run "gradle updatejars" once I know the answer to question #1 that is.
Any ideas? I am just getting into gradle and we really want to keep a consistent environment where when we run our update script, it gets the source code AND the jars in one atomic sweep and we are no longer bothered by checking the repositories every build.
It would be nice to know how to do it by changing the build.gradle file if possible. If not, is there a command line option? (The build.gradle obviously would give me a command line option which is why I prefer that method as I could say compile does not depend on downloading jars).
Regarding the second question. As far as I understand, Gradle will not attempt to do remote lookups or try to download the jar if it is already in the local cache. This should be true for jars declared with a static version, e.g. testCompile 'junit:junit:4.10'.
If you have dynamic versions, e.g. 1.+ or 1.0-SNAPSHOT, etc. then Gradle has to do a check every now and then. You can fine tune the cache expiry for such dependencies.
To make sure Gradle does not do remote lookups you can also use --offline option. See this doc for details.
With regard to svn update, you have at least 3 options:
Try to use an SvnKit plugin for Gradle
Use the ant svn task (here's how to do svn checkout)
Run external command from Gradle. Use the ExecPlugin or just implement it yourself using Groovy API.
Looks like the 1st question I can do with the answer in this post
how to tell gradle to download all the source jars
so I can just gradle eclipse and it will download new jars and update my classpath...nice.