I have a project with several Gradle modules (I think Gradle just calls these sub-projects). Basically I have a bunch of projects/modules listed in settings.gradle. Is there a Gradle command to print each one (either name or ideally a supplied label/description)
Unspectacularly, that task is simply called "projects", and (if you are using the Gradle wrapper) ./gradlew projects executed at the root project lists all sub-projects.
In general, if you are looking for a task, your chances are good that you can guess its name from the task list shown by ./gradlew tasks.
Related
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.
I want to compile one subproject, then have those classes on the classpath while building the other subproject. (A custom tass would use classes created by the first one).
Currently I'm trying:
buildscript {
dependencies {
classpath project(':MyOtherProject')
}
}
... with the following result:
Cannot use project dependencies in a script classpath definition.
You cannot build something to be used to build the something. (something being the multi-project build here)
You either need to make the MyOtherProject a complete separate build, that you either install to some repository and then depend on it per coordinates or trigger that separate build during configuration phase or your build, then depending on its outcomes.
The other alternative is, that you put it into buildSrc project. This is a full multi-project build contained in your root project that is built and added to the classpath of the main build scripts automatically by Gradle and is meant for Plugins and Custom tasks that you do not want to use in other builds also and thus do not make them a separate build.
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.
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.