I have a Library project A and another Library Project B. The project B imports as a compile dependency the project A and I wanted also to add this same dependency for the unit tests, so I can mock some classes from project A (not importing the test folder, but the actual project).
Even with gradle sync working properly, and ./gradlew projectB:dependencies showing the tree with the correct dependencies, in my test classes in project B I cannot access the classes from the A project.
dependencies {
//Project B dependencies
compile project(":projectA")
testCompile project(":projectA")
}
Which is even more fun is that if instead of using the project(":projectA") aka DefaultProjectDependency I use the "group:artifact:version" way aka DefaultExternalModuleDependency by installing Project A locally, it works properly.
For me it sounds like a bug, not sure if it is an Android one or a gradle one.
Versions:
gradle - 2.11
android gradle plugin - 1.5.0
Also opened an issue in b.android: https://code.google.com/p/android/issues/detail?id=201820&thanks=201820&ts=1456399375
Finally this was an error in the Android Plugin and according to the comments in this bug report it will be fixed in 2.0.0 beta 7.
Related
At our company, we use Artifactory to manage artifacts and dependencies of Gradle.
We have library that was build with Gradle 6.0.1, in addition, have a micro-service that was built with Gradle 6.0.1 that is using this library as a dependency.
I verified that this library exists in the declared repo.
When we try to build the project we get an error that this library doesn't exist in the declared repositories and that we should declare the correct one.
The weird part is that if we downgrade the micro-service to Gradle version 5.6.2 the library does get download and working.
We also tested it with other older micro-services that we have based on a template project that is built with Gradle version 4.10.3 and It's also working in them.
What could be the issue?
The library I was referring to in my question didn't have the POM file published with it.
So either I will need to publish it again with the POM being generated (since the library itself was built with Gradle and not Maven - there is a way to generate POM with Gradle)
or:
I will add the following code to build.gradle file so Gradle will download the artifact even though it doesn't have POM file.
repositories {
maven {
url uri('lib')
metadataSources {
artifact()
}
}
}
What is the exact dependency I need to develop a Gradle Plugin in Java? Ideally I would like to get it from a well-known repository such as Maven Central or similar.
I have a Maven project with a core functionality and I just added two extra plugins, one for Ant, one for Maven. They are already tested and working; easy! Now, I wanted to add a third module for a Gradle plugin to make this functionality also available from any Gradle project.
However, I can't find the exact dependencies I need to develop a Gradle plugin.
The Gradle docs (such as https://docs.gradle.org/current/userguide/java_gradle_plugin.html) are not very well written to say the least. They mention:
the gradleAPI() dependency
or the java-gradle-plugin dependency
But they are quite unclear... no group, no version (really?).
If anyone can enlighten me to where I can get these dependencies from, I would be very thankful.
Gradle's public and internal APIs, aka gradleApi(), are bundled with the Gradle distribution and not independently published and therefore not easily consumable by Maven builds. There's the pending epic #1156 (Ensure plugin cross-version compatibility by allowing a user to depend on gradlePublicApi()) that might help here.
Since Gradle plugins are best to be built with Gradle, a pragmatic solution is to invoke the Gradle build from Maven and attach the produced artifact to the Maven build. Andres Almiray (aalmiray) once described this in the blog post Running Gradle Inside Maven (Web Archive Link). He describes the following high level steps:
Create a new Maven module (e.g. gradle-plugin) and add attach it to the parent POM
In the POM of gradle-plugin add a dependency to your core module. Use the maven-dependency-plugin to store dependencies to the Maven build folder, e.g. target/dependencies.
Create the build.gradle, add a Maven repository that points to target/dependencies (step 2) and let it depend on the core module as well as gradleApi(). Implement the Gradle plugin.
Use the exec-maven-plugin to invoke the Gradle build.
Use the maven-resources-plugin to copy the Gradle built plugin jars to the standard Maven build folder.
Use the build-helper-maven-plugin to attach the copied jars to the Maven build.
Sample project to be found here (gradle-in-maven).
https://docs.gradle.org/current/userguide/custom_plugins.html#sec:custom_plugins_standalone_project
In here it is mentioned that it is gradleApi() and I know that this works (from experience). The localGroovy() on that page is only needed if your plugin code uses groovy (does not apply if you only use groovy in the build.gradle of your plugin).
java-gradle-plugin is a library that makes it a bit simpler to make plugins, it is not required though. I personally prefer using gradleApi only.
EDIT:
It appears I've misunderstood the question. Here are the steps to get gradleApi jar:
Create a Gradle project with your desired Gradle version.
Add implementation gradleApi() dependency.
Import/run the project once.
Go to your .gradle folder (located in home folder in Linux-based operating systems).
Open caches folder
Open the version folder you want, e.g. 6.0.1
Open generated-gradle-jars folder.
Copy the jar to wherever you want and use it.
For me the 6.0.1 jar is at ~/.gradle/caches/6.0.1/generated-gradle-jars/gradle-api-6.0.1.jar
Please note that I have not tested this, I know the jar is there but I haven't tried using it.
I have a project that is a library (ProjectLib) and is used in many other projects. I have another project which is a multi project build (MultiProject) with a few sub projects (SubProj1, SubProj2, CoreProj). Some of these sub projects depend on the library project.
Normally I have the sub projects that depend on the library have the library specified in the dependency block of each of their build scripts and it fetches a built version of my library.
Sometimes I have to develop something in my library for this multi project and while doing this I would like to include the library as a composite build so that I can make changes and see the effect in the multi project build.
I have tried adding the path to my library in the settings.gradle of the root project using 'includeBuild' but this only half works.
What I tried is this:
MultiProject settings.gradle
include "SubProj1", "SubProj2", "CoreProj"
includeBuild "../ProjectLib"
SubProj1 and SubProj2 build.gradle
dependencies {
implementation project(":CoreProj")
implementation "com.myCompany:ProjectLib:1.0.0"
}
The build file for the CoreProj doesn't depend on the ProjectLib.
My ProjectLib normally builds to a private repo which is fetched by gradle and so typically version 1.0.0 would be included from this repo. What I would like to happen is that instead of fetching this version of the library, gradle instead includes the project in my local directory so that it has my latest changes without me having to build and release the library to the repo.
What I am getting at the moment is that the ProjectLib is being included in my IDE (I am using IntelliJ) but I get the following warning:
org.gradle.api.artifacts.UnknownConfigurationException: Configuration with name 'default' not found.
This warning appears twice for my MultiProject and the once each for SubProj1 and SubProj2. This also breaks up my project structure in my IDE so that it looks like only CoreProj is included in the multi project build MultiProject.
I am using gradle 5.5.1
I'm migrating an Android multi-module project from Ant to Gradle.
We have some jars in the repo in the libs directory of a library module.
The dependency is as follows:
AppModule depends on LibModule.
The code in AppModule cannot access contents of the library jar that is in LibModule.
Although it can access from-source classes of LibModule (proving that the dependency in general is established).
Gradle documentation says, that all dependencies are transitive by default, but this experience seems to invalidate such claim. Is this a bug or is there some legitimate reason?
I've managed to hack it by adding a workaround dependency in AppModule:
compile fileTree(dir: '../LibModule/libs', include: ['*.jar']) // HACK!
But there should be a more DRY way to do this, right?
Gradle version: 2.1.
Interestingly, Android Studio appears to respect the transitiveness of the jar and does not signal an error.
The error occurs when I'm building using
./gradlew assembleDebug
Thy typical java error is signalled:
error: package net.jcip.annotations does not exist
import net.jcip.annotations.NotThreadSafe;
^
I know I can also specify deps in a maven-ish style, but we would like to be able to work with jars-in-the-repo as well, for our purposes.
TIA, Karol
I'm building an android library project with Gradle using Android Studio. It has some local dependencies:
compile project(':androidlibrary')
with nested, additional external dependencies:
compile group: 'com.google.guava', name: 'guava', version: '14.0.1'
I managed to build the aar file but no external or local dependencies are included. I expect external dependencies to be mentioned in the POM file when published to maven, but what about the local ones?
What is the right way to build such project?
I ended up using "download library from maven" feature of Intellj IDEA as described here. It downloads the library and all it's dependencies to the local directory.
Just a friendly warning: including dependencies is considered a very bad practice at SHOULD BE AVOIDED. It may cause conflicts.
There is no automated way to package the dependencies of the library inside the aar. This is contrary to proper dependency management and can lead to problems down the line.
If you really want to do this, you'd have to gather the dependencies manually (using code in build.gradle) and manually package the files in the aar.