I am working on a project on the side of the main project. The main project used to use ivy so my side project can take advantage of the ivy.xmls and do ivy:resolve to solve all dependencies into a cache.
The main project has moved to gradle and I was wondering if there is a task in the gradle API that can populate gradle cache when I only have the gradle build files.
You can accomplish the same thing with Gradle by configuring a task to copy a configuration to a destination.
task copyDependencies(type: Copy) {
from configurations.runtime
into "$buildDir/deps"
}
Related
I have a root project that includes quite a number of other projects via includeBuild in settings.gradle. All the subprojects have a task named publishToMavenLocal.
How can I define a task publishToMavenLocal in the root project that calls each publishToMavenLocal of each subproject without the need to manually define dependsOn for every subproject specifically?
This use-case is actually covered in the documentation on composite builds. The following code adapts the example from the documentation to your use-case:
task publishToMavenLocal {
dependsOn gradle.includedBuilds*.task(':publishToMavenLocal')
}
In a Gradle project I have multiple sub-projects. I need to copy the dependencies from the configuration of one sub-project to that of another. I can achieve this using the following, adapted from this answer here:
task copyDependencies(type: Copy) {
from project(":sub").configurations.compile
into "${buildDir}/libraries"
}
Unfortunately, with Gradle 5.1, this generates the following deprecation warning (truncated for brevity):
The configuration :sub:compile was resolved without accessing the project in a safe manner. ... This behaviour has been deprecated and is scheduled to be removed in Gradle 6.0.
What's the best way to do this now for Gradle 5.1 and later?
The warning appeared as reaching across project boundaries can cause issues when the build runs in parallel.
The proper way of doing this is to let Gradle know that the project declaring the copyDependencies task will need the project :sub's dependencies.
You can achieve this by doing the following:
configurations {
dependenciesToCopy
}
dependencies {
dependenciesToCopy project(':sub')
}
task copyDependencies(type: Copy) {
from configurations.dependenciesToCopy
into "${buildDir}/libraries"
}
This will cause Gradle to properly create an execution dependency between your project and the resolution of the dependencies of the sub project.
Relevant discussion on the Gradle forums.
I'm working on compiling python bindings using gradle.
There is a plugin by linkedin that facilitates that.
They also include a project called the pivy-importer that converts python dependencies into an ivy repository.
I've created a gradle plugin that wraps the pivy-importer so that it can run as a python task.
My repositories are declared like this:
repositories {
pyGradlePyPi()
ivy {
name 'pypi-local' //optional, but nice
url "${project.buildDir.path}/pythonIvy"
layout "pattern", {
ivy "[organisation]/[module]/[revision]/[module]-[revision].ivy"
artifact "[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]"
m2compatible = true
}
}
}
The problem, however, is that the repositories are being loaded before the plugin executes.
The first task that the python task runs is pinRequirements so I was adding my cusom pythonImporter task before that like this:
pinRequirements.dependsOn pythonImporter
However, even when I do that, the console shows that the pythonImporter task is running before but as soon as it tries to assemble the dependencies, it can't find them even though they do exist in the file system.
If you rerun the task again, however, it passes because the first run added the repository to the file system.
TL;DR
I need a way to run a task before dependencies are looked up under using a project's configured repositories are loaded.
I moved the tasks execution to my buildSrc subproject and made the build task depend upon its execution.
This works because the buildSrc project is always evaluated before the rest of the projects so you can do "before build" logic there.
Without Gradle War Plugin, bootRepackage task depends on jar task but with Gradle War Plugin, it depends on war task.
How can I change it to depend on jar task even though I'm using Gradle War Plugin?
UPDATE:
I'm using war task to create a war file including documents to be deployed to a documentation server and I want to use bootRepackaged jar file to provide a service. My war task depends on asciidoctor task which depends on test task (I'm using Spring REST Docs.) but I don't want to run asciidoctor task or test task when using bootRepackage task.
I solved my problem with the following setup:
ext {
mainClassName = 'com.izeye.throwaway.Application'
}
task myBootRepackage(type: BootRepackage, dependsOn: jar) {
}
but I'm not sure this is a good practice.
This is a sample project having the above configuration:
https://github.com/izeye/spring-boot-throwaway-branches/tree/war
You should have been able to do this:
bootRepackage {
withJarTask jar
}
While this correctly causes the jar task's jar to be repackaged, it doesn't remove the dependency on the war task. This is another symptom of this Spring Boot issue.
Until this issue has been resolved, the approach that you've taken – declaring your own BootRepackage task and manually configuring the tasks that it depends upon – is your best option.
I have multiple projects configured using build.gradle for each and settings.gradle at the top level.
I want to define or use a single Gradle task that will build all of the subprojects and the root.
How do I run or create a single Gradle task to run all subprojects and root in a multi-project build?
It depends on what all your projects are.
You can call gradle(w) build from the root dir if all your subprojects extend the javaplugin.
Other project types (like the ear plugin) need to be attached to the build task manually. The way I do this is by creating the build task like: task build and in the ear project: build.dependsOn ear