What is the difference between "gradle build" and "gradle bootJar"? Why would I use bootJar if I can still create the artifact using build?
build is a lifecycle task contributed by the Base Plugin. It is
Intended to build everything, including running all tests, producing the production artifacts and generating documentation. You will probably rarely attach concrete tasks directly to build as assemble and check are typically more appropriate.
bootJar on the other hand is a specific task added by Spring Boot Gradle plugin that, when the java plugin is present, attaches itself to the assemble lifecycle task.
The assemble task is automatically configured to depend upon the bootJar task so running assemble (or build) will also run the bootJar task.
(Packaging Executable Jars)
You want to use bootJar if you're only interested in building the executable jar and not interested in executing tests, code coverage, static code analysis or whatever is attached to the check lifecycle task.
Related
I have a Gradle build working for a bunch of Java and C sub-modules. I would like to add several sub-modules which are incoming from existing code base and are already setup as Maven builds. Is there a way for Gradle to pickup the Maven sub-modules as part of the parent build?
It seems, there is no native way to run some maven goal within gradle build script. By the way, it is possible to run a maven goal, just providig a custom task of Exec type, which will run a maven build as a command line process. You can read more about this task type here.
Furthermore, it is even possible to provide the maven goal artifacts as dependencies for the gradle project, after you build them from custom gradle task and specify the file-dependency with builtBy property. You can read about it in the official user guide.
what is the difference between assemble and jar task of java plugin in gradle?
I tried executing them with a sample Hello world project they both seems to do the same job.
Since jar is a single task, which assembles a jar-archive for current project, assemble is, according to documentation:
assemble All archive tasks in the project, including jar. Some plugins add additional archive tasks to the project. Task Assembles all the archives in the project.
It is build-cycle task, which execute all the task of this build-cycle phase. Like a check task, which runs all test and verification task, assemble Runs all task, which essemble some artifacts. And the 'jar' could be not the only such a task in the project, some plugins could add them too.
We use maven for our build process and are now modifying it to use grunt to build the client side files. We have maven kick off the grunt task, but similar to maven, there are some things that we want to do only if a certain phase is run. For example, if the deploy phase is run on my maven project, I want to tell grunt to also deploy the js artifact I am creating. Otherwise, if something like compile was run in the maven project, I don't want to deploy my js artifact through grunt.
I can pass properties just fine into grunt, but I don't know how to get a property that can tell me what phase was run. Is it possible to get the phase or the plugin:goal that was run? Or even the command that was run?
The way I have seen other Maven plugins handle this is to use different mojos, bound to the desired phases. For your example, you'd write a deploy mojo and bind it to the 'deploy' phase.
The maven-resources-plugin does this. It has both Resources and TestResources mojos. One is bound to the process-resources phase, the other to process-test-resources. So, if I was to run mvn compile the Resources mojo would execute, but the TestResources mojo would not, as process-test-resources occurs after the compile phase.
Source code for resource plugin
Consider such a situation: there's a big project, which takes tremendous time to compile and I'm having it's resulting artifacts as separate files (jar).
I want to run the unit tests on this project without compiling and jar-ing project itself, so I need to remove dependency on compileJava task, but this task is not in the dependsOn list of test task.
dependsOn property of test task contains only some [file collection] and if I'm printing this FileCollection.files, I'm getting the list of files and directories, which include .../build/classes/main. I think, after removing this entry, I'll get success in removing dependency on compileJava (as I understood, .../build/classes/main is just the result of running compileJava and that's why compileJava appeared). But I just don't understand, how to remove this entry.
By the way, in this case there's no problem of adding this jar to classpath, so that's not an issue.
I'm using Gradle 1.8.
Thanks.
compileJava will be up-to-date if nothing has changed, and jar isn't depended upon by test. If you nevertheless want to add the ability to run tests against a downloaded Jar, declare another Test task. (Reconfiguring test.classpath should work as well, but seems less desirable.)
According to http://www.gradle.org/docs/current/userguide/java_plugin.html and Figure 23.1, the jar task depends on the classes task.
In my scenario I have a multi project containing three projects - ProjectCommon, ProjectApp1 and ProjectApp2. ProjectApp1 depends on ProjectCommon, ProjectApp2 depends on ProjectCommon.
Here's the build.gradle of ProjectApp1 and ProjectApp2:
dependencies {
compile project(':ProjectCommon')
}
I wan't to build now only ProjectApp1, using
$ gradle :ProjectApp1:build
The output shows, that e.g. test and check of ProjectCommon is not executed:
:ProjectCommon:compileJava UP-TO-DATE
:ProjectCommon:processResources UP-TO-DATE
:ProjectCommon:classes UP-TO-DATE
:ProjectCommon:jar
:ProjectApp1:compileJava UP-TO-DATE
:ProjectApp1:processResources UP-TO-DATE
:ProjectApp1:classes UP-TO-DATE
:ProjectApp1:jar
:ProjectApp1:assemble
:ProjectApp1:compileTestJava UP-TO-DATE
:ProjectApp1:processTestResources UP-TO-DATE
:ProjectApp1:testClasses UP-TO-DATE
:ProjectApp1:test
:ProjectApp1:check
:ProjectApp1:build
BUILD SUCCESSFUL
Total time: 4.633 secs
ProjectApp1 is now built without knowing if ProjectCommon is really fine...
(of course I could do gradle :ProjectCommon:build :ProjectApp1:build instead to avoid this).
Wouldn't it be "safer", if jar would generally depend on check?
Or am I doing something wrong with the dependencies and I better should use in build.gradle of ProjectApp1 and ProjectApp2:
dependsOn(':ProjectCommon')
(which gives a deprecation warning)
The Gradle Java plugin uses project compile dependencies only for certain tasks, the check task is not one of them.
In ProjectApp1, add
check {
dependsOn ':ProjectCommon:check'
}
The jar task doesn't depend on the check task because they have no semantic dependency - the latter doesn't produce anything that the former consumes.
Wouldn't it be "safer", if jar would generally depend on check?
It would cost time without being any safer in some cases (e.g. Java compilation), and would not be safe enough in other cases (e.g. when publishing related projects, where you want all projects to be tested before publishing any of them). With Gradle, you can tailor the behavior to the particular needs.
The Java plugin provides a buildNeeded task, which fully builds upstream projects before building downstream projects. In a similar fashion, it would be possible to make Gradle test upstream projects before using their outputs in downstream projects. The question is how useful this would be.