I'm currently using sonarqube LTS(4.5.7) with Findsecbugs plugin installed.
The problem is when running mvn clean install with sonar profile the build fail and it says :Failed to clean project,failed to delete C:..\myproject..\findsecbugs.jar
so it's clear that the findsecbugs.jar cannot be removed in the cleaning phase
i've done some research and it seems that Java process is locking the resource.
Is there anyway to solve the problem knowing that if I kill the Java process it will stop mvn Build.
PS: I cannot move to the latest version of sonarqube since generating issues report in publish mode is no longer supported.
Problem solved by making maven ignore the jar in cleaning phase.
Related
i've created a project with Jhipster, when i open the project with IntelliJ i have these problems in pom.xml:
pom.xml problems
I tried maven clean/package/install, the first two run successfully but when i run maven install a test fails:
test failure
I also tried to use plugin registry (in maven settings) and invalidate caches but still not work. In the end i tried different JDK but i have the same problems. Can someone help me please?
I use JDK 11.0.15, Node 16.15.1, Git 2.36.1 and i'm on windows 10.
For those interested in troubleshooting pom.xml i solved by updating the repository (on IntelliJ go file/settings/build, execution, deployment/build tools/maven/repositories both remote and local) and reloading all maven projects.
This error keeps happening every once in a while in my Kotlin projects. I tried several Kotlin versions (1.3.41, 1.3.60, 1.3.72) but this seems to come up on any version and in various projects. Once it starts happening, I can't build any project.
Full error message:
Unable to load class 'kotlin.coroutines.Continuation'.
Possible causes for this unexpected error include:
Gradle's dependency cache may be corrupt (this sometimes occurs after a network connection timeout.)
Re-download dependencies and sync project (requires network)
The state of a Gradle build process (daemon) may be corrupt.
Stopping all Gradle daemons may solve this problem.
Stop Gradle build processes (requires restart)
Your project may be using a third-party plugin which is not compatible with the other plugins in the project or the version of Gradle requested by the project.
In the case of corrupt Gradle processes, you can also try closing the IDE and then killing all Java processes.
I have tried all the suggestions and none of it helped. When I click
"Re-download dependencies and sync project (requires network)", it says
Clicking "Stop Gradle build processes (requires restart)" restarts Intellij but doesn't help.
Closing Intellij and killing Java processes didn't help either.
While none of the linked suggestions in the error popup worked, running 'clean' gradle task manually did do the trick!
./gradlew clean
The error still comes up every once in a while but can be reliably fixed by running gradle clean.
We are using Dexguard and the latest Fabric Gradle Plugin version 1.25.2. However, when we run the build with Android Plugin for Gradle 2.3.3, we see the gradle task run for '{namespace}:crashlyticsUploadDeobs{flavor + buildvariant}, but with Android PLugin for Gradle 3.0.1, we don't see this gradle task run and the logs in Crashlytics are not de-obfuscated.
My assumption is that this is the task that uploads the Dexguard mapping files up to Crashlytics.
I see the Fabric Gradle Plugin version 1.24.0 changelog indicates that it addressed this very issue for Proguard. Could there be another issue for Dexguard that needs to be addressed in the Fabric Gradle Plugin?
With help from GuardSquare I was able to identify the issue. Dexguard 8.1 provides a 'dexguard-partial' plugin that let's you exclude dexguard for certain buildTypes. By excluding dexguard on debug builds, you get faster build times. However, this 'dexguard-partial' plugin does not appear to be recognized by Fabric's plugin for Gradle. Therefore, those tasks for uploading the Dexguard mapping files to Crashlytics, never run.
I was able to resolve this issue by switching from the 'dexguard-partial', back over to the 'dexguard' plugin and adding the following conditional check to ensure the plugin is only included for Release builds:
getGradle().getStartParameter().getTaskRequests().toString().contains("Release")
This keeps our build times down for debug builds, by excluding dexguard for those builds. And resolves the Crashlytics issue by including dexguard for release builds.
I am trying to build a project with gradle from within Intellij Idea 12 (commercial editon) but this keeps failing. I have the gradle plugin enabled and also the gradle gui plugin. The native project gradle import is working. (I'm not using gradle idea btw.)
When using the bash I only run gradle war to build my web application. Now I want to do the same from within Intellij.
The gradle gui plugin seems to be using the wrong JDK (I guess it's the one Idea uses, a 1.6 JDK) and therefor fails to compile because this is a JDK 1.7 project. And it doesn't integrate well into Idea because it seems like an external build process (like triggering external ant tasks).
What I have done so far is to configure my own artifact in a way that is equivalent to the one gradle war would have build. But that means a lot of configuration and simply feels wrong. There should be a better way?
So what do I have to do to make Idea compile a project in a way similar to the command line gradle task?
JetGradle plugin doesn't provide native tasks support at the moment. It's scheduled for v.12.1 - IDEA-95897. Feel free to track the plugin's news and update it manually as soon as corresponding support is provided.
I have 2 builds of the same project on the same Hudson/Jenkins server (they are running different build profiles). The both build when polling SCM, but I sometimes get the following error:
The plugin 'org.apache.maven.plugins:maven-checkstyle-plugin' does not exist or no valid version could be found
This only started once I added the second build, so I'm assuming there is some sort of conflict. Does anyone know what's going on here?
thanks,
Jeff
Are your builds running at the same time, with the same Maven instance and the same local Maven repository? If so, then maybe you run into a filelock on that plugin jar. I have the same problem here, if two jobs are accessing the same Maven artifact at the same time, they fail, because Maven can't handle that.
I solved that with two Maven instances, with a separate local repository.
It could also help, if you set the VCS polling of the second job a minute after the first job.