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.
Related
I have a Gradle build in which I am publishing the output to the Maven local repo (its used by other modules of a larger non Gradle build). But doing so generates this warning:
Gradle detected a problem with the following location:
'display\build\outputs\apk\release\display-release.apk'. Reason: Task
':display:publishMavenAndroidPublicationToMavenLocal' uses this output
of task ':display:packageRelease' without declaring an explicit or
implicit dependency. This can lead to incorrect results being
produced, depending on what order the tasks are executed. Please refer
to
https://docs.gradle.org/7.2/userguide/validation_problems.html#implicit_dependency
for more details about this problem.
The link suggests that I declare a dependency between the 2 tasks.
But neither of the tasks are custom tasks, they are part of the included plugins. And I despite spending hours trying all kinds of syntax I can't work out how to declare the dependency from the publishToMavenLocal to the package task.
How do I declare it?
plugins {
id 'com.android.application'
id 'maven-publish' // So that we can publish the APKs
}
android {
...
}
publishing {
publications {
mavenAndroid(MavenPublication) {
groupId = 'com.mygroup.foo'
artifactId = project.name
version = 1.2.3'
artifact "$buildDir/outputs/apk/release/${project.name}-release.apk"
// Explicitly not generating a pom dependencies node
// 1) we don't need it because the APK includes all its deps.
on Artifactory.
}
}
}
build.finalizedBy publishToMavenLocal
I believe the problem stems from this line:
artifact "$buildDir/outputs/apk/release/${project.name}-release.apk"
The APK at that location is created by some task. Instead of referencing that tasks' output, you have given a direct path. Because of that, Gradle is not able to accurately deduce task dependencies.
I am not an Android developer, but judging from the error:
uses this output of task ':display:packageRelease' without declaring an explicit or implicit dependency.
The project display has a task named packageRelease which may or may not come from the Android Gradle plugin. Again, I am not an Android developer, so do not know for certain. The packageRelease is what produces the APK at the aforementioned path.
The publishMavenAndroidPublicationToMavenLocal is created when you create a publication named mavenAndroid; this is documented in the maven-publish documentation
With that said, you must declare task dependencies between the two. Something like:
tasks.withType(PublishToMavenRepository::class).configureEach {
inputFile.from(packageRelease)
}
tasks.withType(PublishToMavenLocal::class).configureEach {
inputFile.from(packageRelease)
}
Without knowing the task type of packageRelease and unfamiliarity with Android projects, best I can do above.
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've started to create a Gradle plugin. The build is finishing and producing a valid plugin jar (I think), but the implementation is skeletal. I have a couple of unit tests, but I want to have a very simple way to "system test" the plugin.
The original plugin is in my Eclipse workspace. I want to create a second Eclipse standalone project with a build.gradle that references the jar produced by the other project, just using a relative path to the jar in the other project's "build" folder.
My first stab at this is:
buildscript {
repositories {
jcenter()
mavenCentral()
flatDir {
dirs "../GradleYangPlugin/build/libs"
}
}
dependencies {
classpath files("GradleYangPlugin-1.0.0-SNAPSHOT.jar")
}
}
apply plugin:"com.att.opnfv.yang.gradle"
I then just tried "gradle tasks" to see what it said. It fails with "Plugin with id 'com.att.opnfv.yang.gradle' not found."
You might ask whether I constructed the plugin jar correctly. That's a valid question, but I can show that's not even relevant yet. I ran a File IO monitor (SysInternals ProcessMonitor) while I ran the build, looking for any occurrences of "GradleYangPlugin-1.0.0-SNAPSHOT.jar". The only place it looked for it was in the current directory (the root directory of the second project). This shows that the syntax I used for my "flatDir" element isn't groked by Gradle, and it's also not complaining about it. It just ignores it, seemingly.
gradle multiple build script dependencies
We am in the process from transacting my our build scripts from ant to gradle. The ant build is configured the old way without using ivy and getting the dependencies from a lib folder.
We have a number of custom ant tasks packaged in jar. To run the tasks in that jar we also need some other third parties dependencies from the same lib folder.
Being a complex build we cannot afford to move everything in one go and would rather move one bit at a time as we find some time to do it.
I was able to run those custom ant tasks from the gradle build but I am having problems accessing classes from or tasks jars in my gradle build scripts.
In the build script section we have a class path entry needed for artifactory plugin and I tried to add some more class path entries to make our local libs available.
buildscript {
….
dependencies {
// This dependency below is needed by artifactory plugin which we download
classpath "org.jfrog.buildinfo:build-info-extractor-gradle:3.0.1"
}
….
}
I tried lots of combinations but I could not get it to work. What we want is to be able to do something like below:
buildscript {
…
dependencies {
classpath {
["org.jfrog.buildinfo:build-info-extractor-gradle:3.0.1",
fileset(dir: "${antBuildDir}/customTasks", includes: 'myTasks.jar'),
fileset(dir: "${antBuildDir}/lib", includes: '*.jar')]
}
}
…
}
Any idea about how can I address this or any other suggestions if you think I am on the wrong path.
Thank you in advance.
Julian
I have a small gradle build which is using a 3rd party plugin it works great while running gradle commands I then added the wrapper task so I could distribute the code and it could be built with non gradle users. When I went to test the gradlew command I can not even run gradlew tasks it fails saying the plugin is missing.
Is there some other configuration that needs to happen?
My wrapper task:
task wrapper(type: Wrapper) {
gradleVersion = '1.0-milestone-2'
jarFile = 'wrapper/wrapper.jar'
}
Full build file: https://github.com/beckje01/Multi-Combobox/blob/master/build.gradle
Based on the documentation of this plugin you got to build it from the source code and put it into the directory lib/plugins of your Gradle distribution. My guess is that's what you did before you switched to the Gradle wrapper. Whenever you use the Gradle wrapper your locally installed distribution is not used anymore. Gradle downloads the distribution and puts it under ~/.gradle/wrapper/dists/gradle-1.0-milestone-2. One way to get this running would be to put the plugin in there as you did before. However, this won't make it running for somebody else that checks out your code and runs the build. This is the whole point of using the Gradle wrapper.
What I would do in your case is to upload the plugin artifact to a central repository and refer to it in your build script. It doesn't look like it would be available on Maven Central though. You can upload it to your GitHub project and refer to it in your build script like this:
buildscript {
repositories {
add(new org.apache.ivy.plugins.resolver.URLResolver()) {
name = 'GitHub'
addArtifactPattern 'http://cloud.github.com/downloads/[organisation]/[module]/[module]-[revision].[ext]'
}
mavenCentral()
}
dependencies {
classpath 'beckje01:jslib:0.5'
classpath 'com.google.javascript:closure-compiler:r706'
}
}