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.
Related
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.
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 have a situation where i need to run multiple gradle tasks, in parallel.
For example: I am using gretty(org.akhikhl.gretty:gretty:+) plugin for running embedded webserivce, which runs my service.
So I ran, gradle jettyStart.
Now I have some scripts that need to be ran while the webservice is running, means the gradle jettyRun has run.
I have a migration script written in groovy, which I can call using gradle runScript <script_name>
but since this scripts calls the webservice apis, i need the service to be up. But the case is, once i keep running gradle jettyRun, i cant run gradle runScript until unless i stop the other tasks.
How can I resolve this issue.
You can use start (e.g. appStart) family of gretty tasks which starts jetty in background and exits. Then you can use any other gradle task on this project. To stop jetty you can use stop-tasks
You can get list of available tasks from documentation:
http://akhikhl.github.io/gretty-doc/Gretty-tasks.html
As many of you already know, the Gradle daemon can speed considerably Gradle.
I have a multimodule build and using Gradle wrapper.
When running from the command line:
gradlew :MyModule:test
Gradle spends some seconds analyzing my modules. If I launch again, it consumes the valuable time again and again.
I'm using Gradle 1.12.
I've tried to set add this line:
org.gradle.daemon=true
to local.properties, but no luck.
I don't know if I have to change myHome/.gradle/gradle.properties or some other file.
org.gradle.daemon=true has to be added to gradle.properties, not local.properties.
I have a project with the following subprojects:
foo-codegen
...which, as the name implies, performs code generation...
foo-maven-plugin
...which invokes foo-codegen during the build process.
Generally speaking, this works fine. The problem, though, is when I want to test foo-codegen: foo-maven-plugin isn't yet available during foo-codegen's build cycle if we're putting things together in dependency order, but the build process for the tests invokes that plugin to actually perform the necessary code generation.
What's the right way to break this chain? Should I move foo-codegen's tests into a third subproject? Use the Maven Invoker plugin rather than foo-maven-plugin for doing code generation during the test phase? Something else?
If you do a mvn install or mvn deploy to a repository on the plugin first, then you can run them any order and do a mvn compile separately.