Trying to get my head around if it is possible to use Tasks from other projects in Gradle. Let's say ProjectB is a project with src/main/groovy containing com.MyTask, having parent ProjectA
In build.gradle in ProjectC, also having parent ProjectA:
buildscript {
dependencies{
project(':ProjectB')
}
}
That seems to be legit, because introdusing a typo in "project(:'ProjectB')" fails hard. What also fails is introducing this line:
import com.MyTask
Is project-references not valid in buildscript closure? Also tried moving com.MyTask to buildSrc/src/main/groovy with the same amount of success.
The solution which worked for me was to make "com.MyTask" available both at configurationtime and in sources.
ProjectA(the parent) got this added to buildSrc/build.gradle's sourceSets:
sourceSets{
main{
groovy{
srcDir 'ProjectB/src/main/groovy'
}
}
}
Now ProjectC and all other projects can use MyTask. At the same time it is bundled with the final jar of ProjectB.
The issue has also been discussed thoroughly between between Adam Murdoch, Luke Daley and Steve Ebersole: http://gradle.1045684.n5.nabble.com/buildSrc-as-a-regular-project-td5677255.html
Edit: It was smarter manipulating parent buildSrc than the standalone project. That way IntelliJ is happy-go-lucky.
From Gradle documentation 15.4. Adding dependencies to a task:
Example 15.13. Adding dependency on task from another project
build.gradle
project('projectA') {
task taskX(dependsOn: ':projectB:taskY') << {
println 'taskX'
}
}
project('projectB') {
task taskY << {
println 'taskY'
}
}
Related
"refresh all gradle projects" in Intellij Idea gives me following error:
Error:(15, 0) Cannot change dependencies of configuration ':util:compile' after it has been included in dependency resolution.
The problem doesn't occur when I move second if statement to build.gradle of submodule project. While I found workaround I would like to understand why original solution is not correct. The line making trouble is:
"Class-Path": (configurations.compile.collect {"$dependencyDir/$it.name"}.join(" "))
Project structure:
mcv-gradle-example
|__ submodule (gradle project)
|__ util (gradle project)
|__ build.gradle
build.gradle:
allprojects {
apply plugin: 'java'
}
subprojects {
apply plugin: 'scala'
repositories {
mavenCentral()
}
def isSpecialProject = project.name in ["submodule"]
dependencies {
compile group: 'org.scala-lang', name: 'scala-library', version: '2.12.1'
if (isSpecialProject) {
compile project(':util')
}
}
if (isSpecialProject) {
def dependencyDir = "/deps"
task setupJarManifest() {
jar.manifest.attributes(
"Class-Path": (configurations.compile.collect {"$dependencyDir/$it.name"}.join(" ")))
}
jar.dependsOn setupJarManifest
}
}
Update:
I found out that embracing jar.manifest... with afterEvaluate allows having this task in main build.gradle. However I'm still not sure what was the gradle's problem.
Update 2:
It seems moving setting manifest.attributes to the execution phase solves he problem. My final solution is:
if (isSpecialProject) {
def dependencyDir = "deps"
jar {
doFirst {
manifest.attributes(
"Class-Path": (configurations.compile.collect {"$dependencyDir/$it.name"}.join(" "))
)
}
}
}
My guess is:
When submodule project uses configurations.compile in configuration phase, it's all dependencies are resolved. Then the subprojects closure is evaluated for util project. Since util is dependency of submodule it can't have new dependency added as one moment ago we used it's all dependencies. It's reasonable but still I don't know how usage of configurations.compile "marks" util's dependencies as closed.
Explanation
After some more research I finally know what happened:
Subproject submodule is evaluated first. It puts scala and subproject util into its dependencies.
Then gradle evaluates configurations.compile.collect which internally calls iterator method calling DefaultConfiguration#getFiles. To find what files are specified for this configurations it resolves graph and artifacts (locking it's dependencies modification abilities).
Then subprojects closure is evaluated for subproject util. It is trying to put scala in its dependencies but is locked because of point 2 so it throws an error.
Moving collect to afterEvaluation or doLast executes it after correct resolution of graph and artifacts. It can be called as many times as you want in execution phase.
I have a project which is using Gradle as build tool and a second subproject which is using Maven's POM. I don't have the freedom of changing build tool on the subproject.
What I want to achieve is to add my project with Maven POM as dependency on my Gradle project.
Where root (current dir) is my project with Gradle and contains the build.gradle, the Maven project is under vendor/other-proj/ with POM file just under that directory.
I have tried these variations on my build.gradle file:
1st try:
include("vendor/other-proj/")
project(':other-proj') {
projectDir = new File("vendor/other-proj/pom.xml")
}
dependencies {
compile project(':other-proj')
}
2nd try:
dependencies {
compile project('vendor/other-proj/')
}
3rd try:
dependencies {
compile project('vendor/other-proj/pom.xml')
}
4th try:
dependencies {
compile files 'vendor/other-proj/pom.xml'
}
I can't find anything related on the web, it seems most Gradle/Maven use cases are affected by publishing to Maven or generating POM, but I dont want to do any of those.
Can anybody point me to right direction?
you can "fake" including a Maven project like this:
dependencies {
compile files("vendor/other-proj/target/classes") {
builtBy "compileMavenProject"
}
}
task compileMavenProject(type: Exec) {
workingDir "vendor/other-proj/"
commandLine "/usr/bin/mvn", "clean", "compile"
}
This way Gradle will execute a Maven build (compileMavenProject) before compiling. But be aware that it is not a Gradle "project" in the traditional sense and will not show up, e.g. if you run gradle dependencies. It is just a hack to include the compiled class files in your Gradle project.
Edit:
You can use a similar technique to also include the maven dependencies:
dependencies {
compile files("vendor/other-proj/target/classes") {
builtBy "compileMavenProject"
}
compile files("vendor/other-proj/target/libs") {
builtBy "downloadMavenDependencies"
}
}
task compileMavenProject(type: Exec) {
workingDir "vendor/other-proj/"
commandLine "/usr/bin/mvn", "clean", "compile"
}
task downloadMavenDependencies(type: Exec) {
workingDir "vendor/other-proj/"
commandLine "/usr/bin/mvn", "dependency:copy-dependencies", "-DoutputDirectory=target/libs"
}
You cannot "include" a maven project in gradle settings.gradle. The simplest way would be to build the maven project and install it to your local repo using mvn install(can be default .m2, or any other custom location) and then consume it from your gradle project using groupname:modulename:version
repositories{
mavenLocal()
}
dependencies{
implementation 'vendor:otherproj:version'
}
It is possible to depend directly on the jar of the maven project using compile files but this isn't ideal because it wont fetch transitive dependencies and you'll have to add those manually yourself.
How can I tell gradle to build a certain sub-projects first, even though I don't have a compile dependency to them? How are project dependencies handled internally?
Example:
settings.gradle:
include "app", "schema"
build.gradle:
allprojects {
apply plugin: 'java'
}
schema/build.gradle:
// empty
app/build.gradle:
configurations {
schemas
}
dependencies {
schemas project(":schema")
schemas "org.example:example-schema:1.0"
}
task extractSchema(type: Copy) {
from {
configurations.schemas.collect { zipTree(it) }
}
into "build/schemas"
}
//compileJava.dependsOn extractSchema
And when running:
$ cd app
$ gradle extractSchema
I get:
Cannot expand ZIP 'schema/build/libs/schema.jar' as it does not exist.
What I want is that gradle automatically builds all sub-projectes defined in the configurations.schemas dependency list first (if they are projects).
Note: I want to be able to share the extractSchema task across multiple gradle projects, so it is important that gradle takes the list of sub-project to be built first from the configurations.schemas list.
Thanks
Gradle build order is never on the project level, but always on the task level. from(configuration.schemas) would infer task dependencies automatically, but in case of from(configuration.schemas.collect { ... }), this doesn't work because the resulting value is no longer Buildable. Adding dependsOn configurations.schemas should solve the problem.
In order to release my system, I am creating a releaser project that calls uploadArchives for a number of other projects.
In my project I have the following files:
settings.gradle
include '../proj-a', '../proj-b'
build.gradle
task releaseSystem() {
// what goes here?
}
What should the contents of the releaseSystem task be such that I can call gradle releaseSystem and have it run uploadArchives for each of my sub projects?
I've tried a number of options, but none have been successful thus far.
Thank you for any insights you can provide.
ANSWER
I'm continually impressed with the graceful solutions gradle provides to my problems. Here's my final solution (as Peter pointed out below):
settings.gradle
include 'proj-a', 'proj-b'
project (':proj-a').projectDir = new File(settingsDir, '../proj-a')
project (':proj-b').projectDir = new File(settingsDir, '../proj-b')
build.gradle
task releaseSystem() {
dependsOn {
[
subprojects.build,
subprojects.uploadArchives
]
}
}
Note, that since my repository is a maven repository, when I originally included '../proj-a' in my settings.gradle, it produced poms with artifactId ../proj-a which was invalid. I had to change my settings.gradle to the format above for the system to put the poms together correctly and for the uploadArchives task to complete successfully.
Assuming all subprojects have an uploadArchives task:
task releaseSystem {
dependsOn { subprojects.uploadArchives }
}
Note that this won't run the subprojects' tests.
I had quite good gradle configuration, that built everything just fine. But one of the projects of my multi-project build derived from the rest of them so much, that I would gladly move it to another git repo and configure submodules to handle it.
First, I moved Project and its resources to subfolder Libraries/MovedProject. After altering some lines in gradle configurations it worked fine. But then I decided to write a new build.gradle just for this project, and move all configurations there from the main one.
And this is where everything stopped working. When I try to call any task it always ends
with Could not find property 'sourceSets' on project ':Libraries/MovedProject'. Line which is responsible for it is:
dependencies {
...
if (noEclipseTask) {
testCompile project(':Libraries/MovedLibrary').sourceSets.test.output
}
}
which I use for running tests in which I use classes from other projects. If I remove that line, the build fails only when it reaches compileTestJava task of projects that make use of MovedProject. If I remove that line and call gradle :Libraries/MovedLibrary:properties I can see :
...
sourceCompatibility: 1.7
sourceSets: [source set main, source set test]
standardOutputCapture: org.gradle.logging.internal.DefaultLoggingManager#1e263938
...
while gradle :Libraries/MovedLibrary:build builds correctly.
Currently I've got everything set up as following:
directories:
/SomeMainProject1
/SomeMainProject2
/SomeMainProject3
/Libraries
/MovedProject
build.gradle
dependencies.gradle
project.gradle
tasks.gradle
/Builder
dependencies.gradle
project.gradle
tasks.gradle
build.gradle
settings.gradle
settings.gradle
include Libraries/MovedProject,
SomeMainProject1,
SomeMainProject2,
SomeMainProject3
sourceSets for MovedProject are defined in Libraries/MovedProject/project.gradle:
sourceSets {
main {
java {
srcDir 'src'
srcDir 'resources'
}
resources { srcDir 'resources' }
}
test { java {
srcDir 'test/unit'
} }
}
dependencies that makes use of sourceSets.test.output are stored in Builder/dependancies.gradle, and set for each project that needs MovedProject to run tests:
project(':SomeMainProject1') {
dependencies {
...
if (noEclipseTask) {
testCompile project(':Libraries/net.jsdpu').sourceSets.test.output
}
}
}
What would be the easiest way to get rid of that error and make gradle build projects with current directory structure? I would like to understand why gradle cannot see that property.
The line in question is problematic because it makes the assumption that project :Libraries/MovedLibrary is evaluated (not executed) before the current project, which may not be the case. And if it's not, the source sets of the other project will not have been configured yet. (There won't even be a sourceSets property because the java-base plugin hasn't been applied yet.)
In general, it's best not to reach out into project models of other projects, especially if they aren't children of the current project. In the case of project A using project B's test code, the recommended solution is to have project B expose a test Jar (via an artifacts {} block) that is then consumed by project A.
If you want to keep things as they are, you may be able to work around the problem by using gradle.projectsEvaluated {} or project.evaluationDependsOn(). See the Gradle Build Language Reference for more information.
I had a similar error happen to me in a multimodule project, but for me the cause was as simple as I had forgotten to apply the java-library plugin within the configurations, I only had maven-publish plugin in use.
Once I added the plugin, sourceSets was found normally:
configure(subprojects) {
apply plugin: 'maven-publish'
apply plugin: 'java-library'
....