I'm currently trying to migrate a project from Gradle 3.5 to the latest Gradle version 4.9. and I'm running into the problem, that Gradle doesn't find the resources that it needs to execute the junit tests. These resources are generated upfront and contain some configuration files and referential data.
The project uses a combination of npm and Gradle to compile. Usually we run a npm script which executes a couple of tasks sequentially using run-s, e.g. webpack builds to generate some static resources. At the end we compile everything together using Gradle. The last Gradle task also executes the junit tests. This step fails and makes the whole build fail. The Gradle runner complains that some resources are not found, although the get properly copied to the right places.
When I execute ./gradlew test --rerun-tasks (Yes, we use the wrapper, which has been properly upgraded, too) right after the last Gradle build step failed, it executed the junit tests successfully.
I know, that the directory structure changed in Gradle 4.x, but this doesn't seem to be the problem.
My suspicion is, that it has something to do with how we normally run the whole build process. Something in the combination with npm.
Related
When generating a skeleton Maven plugin from archetype, the new project includes a Maven project under the src/it directory. It is an integration it (hinted at by the it dir name) and fresh out-of-the-box it passes when run during Maven's integration-test phase.
There are nearly 10 such IT Maven projects, a subset of which intentionally result in BUILD FAILURE, and attendant verify.groovy scripts that ensure those builds fail for the correct reason. Ideally each IT test sub-build that fails for the correct reason results in that IT test passing, but by including any of these failing IT tests as part of the whole integration test suite causes the overall Maven run to fail as well, which is incorrect in my case.
How do I coax Maven to run those failing Maven sub-builds, ignore their build results, but honor the results of their Groovy verification scripts?
Edit: One IT test (disabled) is committed here.
If you like to write an integration test which is intended to fail as a result
you have to express this via the invoker.properties file like this:
invoker.buildResult=failure
The full description of the file can be found in the documentation.
We have a Gradle 5.x multi-module project consisting of four modules written in Java and a plugin written in groovy. When the modules were in separate git repos, we had coverage for the plugin because the tests ran. With everything in one repo, it now no longer runs the groovy tests, yet it runs all of the Java tests. We've tried setting the classes directories explicitly in test {
jacoco {
includes = [dirs here...]
but it has no effect. There doesn't seem to be anything online about this problem. Has anyone seen it? If so, what's the fix?
In SpringBoot application, what is the difference between
type ./gradlew and execute main method in **App.java?
I'm in chaos. I thought execute main method contains ./gradlew task. But it seems like doesn't contains that.
Because the result was different when I execute both task.
the w in gradlew is for wrapper as stated in gradle official website:
The recommended way to execute any Gradle build is with the help of the Gradle Wrapper (in short just “Wrapper”). The Wrapper is a script that invokes a declared version of Gradle, downloading it beforehand if necessary. As a result, developers can get up and running with a Gradle project quickly without having to follow manual installation processes saving your company time and money.
I'm new to Gradle. I see that Gradle lib already has a file 'groovy-all-2.4.12.jar' in lib folder and I don't seem to have any issues with tasks and or dependencies. Still, is it necessary in any scenario to install Groovy on my system on top of it?
Reason why I ask is that, when I do 'gradle -v' in command prompt, I see few warnings. Please see attached screenshot.
With gradle it is strongly recommended to use the Gradle wrapper committed into the project you are building instead of a system-wide gradle distribution (that is gradlew and not gralde). This guarantees the matching version of Gradle your project has been tested with.
With the Gradle wrapper you do not need to care about any dependencies that Grade itself needs, such as groovy and you really do not need to install anything of Gradle at all as the wrapper in your project will download all it needs on the first run.
The minimum setup for the Gradle wrapper is:
/gradlew - unix shell script
/gradlew.bat - windows batch script
/gradle/wrapper/gradle-wrapper.properties -- the properties file defining the version
/gradle/wrapper/gradle-wrapper.jar -- the minimal jar (50Kb) that takes care about the rest
The above files must be committed into your project and this is what 99% of all gradle projects do. You will find further details here https://docs.gradle.org/current/userguide/gradle_wrapper.html
I just converted my Maven project to a gradle project. It was a multi project structure:
master-project
pom.xml
---->project1
-------->pom.xml
---->project2
-------->pom.xml
---->project3
-------->pom.xml
I ran a gradle init on it and have this structure now:
master-project
build.gradle
---->project1
-------->build.gradle
---->project2
-------->build.gradle
---->project3
-------->build.gradle
Everything builds fine, and I have been able to get some things done with that I couldn't figure out how to do with Maven, so that's great. Next step was to integrate that into the IDE since the Maven Dependencies are gone since I have removed the pom.xml files.
However the project isn't recognized as a gradle project - and I am not sure how to change that?
In Eclipse Mars it's still recognized as a Maven build, not gradle....
Thanks in advance.
EDIT: I reimported the projects which enabled the plugin for Eclipse. Now I am having weird behavior.
The build works from the command line, however when attempting the same execution from within Eclipse, it fails trying to copy the file dependencies.
For example:
Couldn't copy dependency jakarta-regexp-1.4.jar
java.nio.file.NoSuchFileException: C:\Users\user.m2\repository\jakarta-regexp\jakarta-regexp\1.4\jakarta-regexp-1.4.jar -> build\jfx\app\lib\jakarta-regexp-1.4.jar
I haven't changed the repo from maven yet - just changed the build scripts. This is running from the master project. So I am confused as to why the script would work from the commandline but not from within eclipse.
EDIT 2: Turns out this behavior is also present when running from the command line when the --daemon flag is set. Is there anyway to run the tasks without the daemon in Buildship? Or perhaps a way to fix this issue when the --daemon flag is enabled?
Thanks.
The issue with the build was that there is a leak in the JDK when bundling the JRE with the native app. This only happens when running with the --daemon flag (which all IDEs user). Therefore until this is fixed you will need to run gradle --stop and then run the clean.
The plug in I am using is no longer running the native task when running with --daemon.