I am playing with the example project at:
https://github.com/bmuschko/gradle-in-action-source/tree/master/chapter06/listing_06_03-todo-project-dependencies
After I run the jettyRun task at the "web" subproject I got:
:model:compileJava UP-TO-DATE
:model:processResources UP-TO-DATE
:model:classes UP-TO-DATE
:model:jar UP-TO-DATE
:repository:compileJava UP-TO-DATE
:repository:processResources UP-TO-DATE
:repository:classes UP-TO-DATE
:repository:jar UP-TO-DATE
:web:compileJava UP-TO-DATE
:web:processResources UP-TO-DATE
:web:classes UP-TO-DATE
:web:jettyRun
However in the gradle it only says "web" project depends on "repository" and "repository" depends on "model" which are project level dependencies. So when you run "jettyRun" how does gradle know which tasks to run in the subproject?
When you declare that one project is dependent on another project this means that the first project is dependent on the artifact of the other project. In the java plug-in this artifact is produced by the jar task.
Related
This is my basic setup:
// Dependencies
repositories {
maven { url "http://MYREPO.." }
jcenter()
mavenLocal()
}
dependencies {
compile 'org.bytedeco.javacpp-presets:opencv:3.1.0-1.2'
}
From my understanding of how dependency resolution works, gradle should try and seek for the dependency first in my repo, then in jcentral() and then in mavenLocal.
Instead, I get this output on ./gradlew assemble:
:compileJava
Download http://MYREPO.../org/bytedeco/javacpp-presets/opencv/3.1.0-1.2/opencv-3.1.0-1.2.jar
:processResources UP-TO-DATE
:classes
:jar UP-TO-DATE
:assemble UP-TO-DATE
BUILD SUCCESSFUL
In fact, when I take a look inside my repository to see what happens, I found the opencv dependency being PUSHED as a consequence of the dependency resolution.
I would expect instead the artifact to be downloaded from jcenter, where it's in fact present.
I am using apache archiva.
Why does this happen?
Is this behaviour documented somewhere?
I don't undrstand if this is a problem with my repository settings or with the gradle script.
If your repository is mirroring the central repo, then what happens is this:
Gradle tries to find a dependency from your repo
Your repo does have it, so it contacts the upstream repo that it is mirroring
Dependency is downloaded from the upstream repo and is cached in your repo
Dependency is handed to Gradle
This never leaves Gradle the chance to try to contact jcenter directly :)
For Apache Archiva, the caching settings are configurable under "Proxy Connectors" and documented here:
http://archiva.apache.org/docs/1.4-M4/adminguide/proxy-connectors.html
You can basically choose how frequently (or not at all) to cache the artifacts from the mirrored repo for use in subsequent requests.
I am migrating to Gradle as my build tool for a Java project.
My main project (A) has a dependency on other projects (B and C).
At the moment each of these projects are in CVS individually and when I want to compile A I have to check out A, make a subdir in A called B in which I check out B. Same goes for C.
Im going to migrate to repository manager (nexus) in which B and C can be published to. When this happens, module A can just have a dependency on B and C which it can get from nexus.
However, the difficulty arises if I do not want to publish B and C (for testing purposes) and I want to build A with my latest code from B and C without committing it to nexus.
My initial thoughts on this are to build the jar for B and C and pull it into the "lib" folder for A. However Im sure there is a better way.
In maven I could do a "mvn clean install" which would install B and C in my local maven cache. A would then look there for the appropriate jars.
But Im still not sure this is the best way. I had a look into gradle subprojects but I dont fully understand them. How would the submodules handle in an SCM (would I also need to use git submodules?)
I would appreciate some guidance as to best practices for this situation.
Thanks
EDIT:
The reply below from Vyacheslav Shvets is the most accurate answer I have found so far.
There is one other way of switching out a gradle project dependency with maven-style dependency. This involves dependency substitution as described at https://docs.gradle.org/current/userguide/dependency_management.html#sec:project_to_module_substitution
This can be wrapped around a:
if(project.hasProperty("someSwitch")){
configurations.all{.....
....
}
}
Usage of this method would be:
gradle build -Psomeswitch
The old (classical) way
The same approach as for Maven:
Apply maven plugin on project B
Run gradle clean install on project B
Actually, you don't have to clean every time if your build correctly uses task inputs and outputs
In project A, add mavenLocal() repository and run build
The new way (experemental) - Composite build
A composite build allows you to combine multiple Gradle builds and replace external binary dependencies with project dependencies as if you were using a single multi-project build
https://docs.gradle.org/2.13/release-notes
This is not fully available yet. Since 2.13 you can use it via Tooling API (for example, Buildship 2.0 plugin for Eclipse IDE). The common usage will be available in 3.1, but you can try it now using nightly builds of 3.1
If you download and execute demo build from Gradle's github with latest nightly build you will see the following:
$ gradle build
[composite-build] Configuring build: C:\Users\Shvets\repos\composite\projectB
[composite-build] Configuring build: C:\Users\Shvets\repos\composite\projectC
:compileJava
:projectB:b1:compileJava
:projectB:b1:processResources UP-TO-DATE
:projectB:b1:classes
:projectB:b1:jar
:projectB:b2:compileJava
:projectC:compileJava
:projectC:processResources UP-TO-DATE
:projectC:classes
:projectC:jar
:projectB:b2:processResources UP-TO-DATE
:projectB:b2:classes
:projectB:b2:jar
:processResources UP-TO-DATE
:classes
:jar
:assemble
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test UP-TO-DATE
:check UP-TO-DATE
:build
BUILD SUCCESSFUL
Total time: 4.497 secs
For deep understanding, see demo video of both approaches.
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.
I am trying to generate groovydocs in gradle script using command gradle groovydoc. I can see the command executed successfully as below:
Dynamic properties are deprecated: http://gradle.org/docs/current/dsl/org.gradle.api.plugins.ExtraPropertiesExtension.html
:compileJava UP-TO-DATE
:compileGroovy UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:groovydoc UP-TO-DATE
BUILD SUCCESSFUL
But I don't see any API generated in the file system. What am I missing here?
Given the information you provide, it's impossible to say. We'd have to see the build scripts, output of gradle -v, etc. The first line of output indicates that you may have misspelled a configuration property in the build script. Recent versions of Gradle will print the property in question. If you get the UP-TO-DATE even for gradle clean groovydoc, it's a clear sign that something isn't configured correctly.
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.