Develop Reference

Gradle Dependency Implementation

I am having two project(ProjectA and projectB). ProjectA have 2 tasks of creating jarA1.jar and jarA2.jar. This is configured with ProjectA's build.gradle. Now I want to add these two created jars as dependency to ProjectB , by just mentioning the project and not specifying the jar's file path separate.
Suppose in future if I add multiple jars at ProjectA , all the jars must be added as dependency to ProjectB without any changes in projectB's build.gradle.
ProjectA => build.gradle
task jarA1(type: Jar, dependsOn: compileGrpcJava) {
...
}
task jarA2(type: Jar, dependsOn: compileGrpcJava) {
...
}
jar {
dependsOn jarA1
dependsOn jarA2
}
ProjectB => build.gradle
Approach1:
dependencies {
implementation project (:ProjectA)
}
is not importing the Jars. But this works.
Approach2:
dependencies {
implementation project (:ProjectA)
implementation files('<path_to_jarA1.jar')
implementation files('<path_to_jarA2.jar')
}
Can anyone say why approach 1 is not working. Why adding the complete project as dependency not taking up all the jars of that project by default?

Gradle to add module dependency in Micronaut project

I have three module as shown below
The fete-bird-apigateway depend on common and fete-bird-product depend on both fete-bird-apigateway and common
In the fete-bird-product settings.gradle I have included the code below
rootProject.name = "fete-bird-product"
include 'fete-bird-apigateway' , 'common'
and in the build.gradle of project
dependencies {
implementation project(':common')
}
Error
Caused by: org.gradle.internal.component.NoMatchingConfigurationSelectionException: No matching configuration of project :common was found.
I don't want to create a multi-module build project describe here https://docs.gradle.org/current/userguide/multi_project_builds.html. Each project should build individually and dependent modules should load while building.
How can I achieve this?

Well I found that I had the wrong concept for different module projects.
Assuming all modules are part of the same multi-module build then in fete-bird-apigateway.gradle and service\build.gradle you add:
plugins {
id 'java'
id 'maven-publish'
}
dependencies {
implementation project(':common')
}
However if common, fete-bird-apigateway and service are separate projects and don't share the same root build.gradle you have to publish the common module into a shared repository and use it like any regular dependency. Easiest to do with Maven Local repository.
To publish to the local maven
In fete-bird-apigateway.gradle
publishing {
publications {
maven(MavenPublication) {
groupId = 'org.gradle.sample'
artifactId = 'library'
version = '1.1'
from components.java
}
}
}
Reference - https://docs.gradle.org/current/userguide/declaring_repositories.html
https://docs.gradle.org/current/userguide/publishing_maven.html#gsc.tab=0
In the dependent project add the dependency as regular
repositories {
mavenLocal()
}
implementation("fete.bird:fete-bird-apigateway:0.1")
We need to run the task or gradle command for publish. I am using Intellj so did with below task
We can run the gradle command gradle publishToMavenLocal

How to generate all-projects-in-one Gradle project?

I have a gradle monolithic project with too many dependencies.
I'd like to explode it into many sub-projects and publish all sub-projects (build + sources + javadoc) + an extra project being the merge of all sub-projects.
This extra project should be like a virtual artifact with all my projects in a single jar like it is today because I don't want a too big change for my users.
The jar must not include dependencies (it is not an uber-jar) but the resulted pom.xml must contain the dependencies of all sub-projects (the generated pom.xml of the maven artifact must contain all dependencies).
The virtual artifact will include the merge of javadoc and sources too in order to respect Maven Central conventions.
Current state:
Project Main, generate
pom.xml
main.jar
main-sources.jar
main-javadoc.jar
Expected state:
Subproject A, generate
A-pom.xml
A.jar
A-sources.jar
A-javadoc.jar
Subproject B, generate
B-pom.xml
B.jar
B-sources.jar
B-javadoc.jar
virtal-Project Main, generate
pom.xml=A-pom.xml+B-pom.xml
main.jar=A.jar+B.jar
main-sources.jar=A-sources.jar+B-sources.jar
main-javadoc.jar=A-javadoc.jar+B-javadoc.jar
How can I manage it?

We have been in exactly the same situation for some time now. We want to publish a single artifact for our clients to depend on, although internally the product is developed through a few separate component projects. I got it done eventually (with compromises), and here is what I learned:
Merging jars is not as straightforward as it looks like because there could be things like resource files within a jar that are not
always namespace-ed. It is possible that two of your jars have a
resource file with the same name, in which case you will have to
merge the content of those files.
Javadoc is very hard to merge without accessing the original source
files because it has summary pages (index pages).
So my advice would be:
Think twice, maybe what you really want is NOT a single jar, but a single dependency for your clients? These are different. You can easily have a pom only artifact. Depending on this pom only artifact will simply translates transitively into depending on individual artifacts of your component sub projects. To your client, practically, nothing is changed. Spring Boot takes this approach. To do it, you can create an empty java-library project, make all your component projects its api dependency. You don't even need any source code in this project.
If you really want to merge into a single jar, you can try building a fat jar with customization. The customization is not to pull in 3rd party dependencies.
We use the Gradle Shadow plugin for merging jars. Its original purpose was to build a fat jar, which will include all the transitive dependencies. But it also has a special "shadow" configuration, to which you can add dependencies if you want the dependencies to be exported into POM rather than bundled. So what you need to do:
Define a non-transitive configuration (say bundler) to which you will add your sub-project as dependencies. This is going to be the target configuration for the Gradle Shadow plugin.
Define a transitive configuration (bundlerTransitive) that extends from your non-transitive one. This will be manually resolved in order to find the 3rd party dependencies
in your build.gradle, register an afterEvaluate closure, where you find the level two dependencies of the resolved transitive configuration, add them to the shadow configuration. The reason for level-two is that level one dependencies will be your sub-project artifacts.
After all the above, the artifact produced by shadowJar task is the one to be uploaded to maven. You will need to configure the shadowJar task to remove the classifier (which is shadow by default)
Here is a complete example (build.gradle) of bundling vertx-web and all its dependencies within the io.vertx group:
plugins {
id 'java'
id 'maven-publish'
id 'com.github.johnrengelman.shadow' version '5.2.0'
}
group 'org.example'
version '1.0-SNAPSHOT'
repositories {
mavenCentral()
}
configurations {
bundler {
transitive = false
}
bundlerTansitive {
extendsFrom bundler
transitive = true
}
}
dependencies {
bundler "io.vertx:vertx-web:4.0.0"
bundler "io.vertx:vertx-web-common:4.0.0"
bundler "io.vertx:vertx-core:4.0.0"
bundler "io.vertx:vertx-auth-common:4.0.0"
bundler "io.vertx:vertx-bridge-common:4.0.0"
}
shadowJar {
configurations = [project.configurations.bundler]
classifier ''
}
publishing {
publications {
shadow(MavenPublication) { publication ->
project.shadow.component(publication)
}
}
}
project.afterEvaluate {
// this is needed because your sub-projects might have inter-dependencies
def isBundled = { ResolvedDependency dep ->
return configurations.bundler.dependencies.any {
dep.moduleGroup == it.group && dep.moduleName == it.name
}
}
logger.lifecycle '\nBundled artifacts and their 1st level dependencies:'
// level one dependencies
configurations.bundlerTansitive.resolvedConfiguration.firstLevelModuleDependencies.forEach {
logger.lifecycle "+--- ${it.getName()}"
// level two dependencies
it.children.findAll({ ResolvedDependency dep -> !isBundled(dep) })
.forEach { ResolvedDependency dep ->
logger.lifecycle "| +--- ${dep.name}"
project.dependencies.add('shadow', [group: dep.moduleGroup, name: dep.moduleName, version: dep.moduleVersion])
}
}
logger.lifecycle '\nExported Dependencies:'
configurations.shadow.getResolvedConfiguration().getFirstLevelModuleDependencies().forEach {
project.logger.lifecycle "+--- ${it.getName()}"
}
}
For javadoc if you don't care about the index (compromise, as I said), then it is just a jar task with a copy spec:
configurations {
javadoc {
transitive = false
}
}
dependencies {
javadoc 'com.my:component-a:1.1.0:javadoc'
javadoc 'com.my:component-b:1.1.0:javadoc'
javadoc 'com.my:component-c:1.1.0:javadoc'
javadoc 'com.my:component-d:1.1.0:javadoc'
}
task javadocFatJar(type: Jar) {
archiveClassifier.set('javadoc')
from {
configurations.javadoc.collect { it.isDirectory() ? it : zipTree(it) }
}
with jar
}

This cannot be done with maven-publish directly, but one can add individual java-library modules and package each of them with sources and docs. With Gradle this would be a simple jar task, but when the artifacts are publicly available ...such transitive dependencies should better be provided by a meta package; nothing but Maven (Local/Central) dependencies, instead of embedded JARS. In this case, this would be just another module (which obviously would only build after having published the others).
And concerning the concept, that it would require any "merged" JavaDocs ...
https://central.sonatype.org/pages/requirements.html#supply-javadoc-and-sources
While they're referenced (Maven Central) in *.pom, Gradle will be able to find them.
Just use repository mavenLocal() instead of mavenCentral() for testing purposes.

Gradle multiproject multiple dependencies

I have a gradle project like this:
root
|
|---- projectA
|
|---- projectB
...
My root build.gradle contains dependencies which are needed for projectA and projectB. I have defined them like this:
subprojects {
repositories {
jcenter()
mavenCentral()
mavenLocal()
}
dependencies {
compile 'com.google.guava:guava:23.0'
compile group: 'com.google.code.gson', name: 'gson', version: '2.8.2'
Now I am trying to add a dependency on projectA from projectB so my projectB build.gradle looks like this:
dependencies {
implementation project(':projectA')
}
and projectB settings.gradle:
include ':projectA'
project(':projectA').projectDir = new File(settingsDir, '../projectA')
This is currently failing, as projectA and B do not depend on root to get their needed dependencies.
Can I add another dependency from projectA on root or what is the default gradle approach to share same dependencies from one root project?

Specifying dependencies with the "compile" keyword is being deprecated. The new keyword to use is "implementation". (See this SO question for an example of explanation.) The difference between "compile" and "implementation" as it relates to your case, is that "compile" propagates the dependency to all connected modules, while "implementation" is single-level. So, if you have
root
module A
module B
and module B has a depandency brought in with "compile", then root has access to that dependency.
But if you now change B to bring the dependency in with "implementation", then you'll still need to add the dependency to the root project's build.gradle.
Why is this relevant? Because a child module isn't allowed to know who its parent is. So, while A and B both see the dependencies you brought into root, they really shouldn't -- seeing those dependencies is a quirk of how Studio works. This is also why the answer to "Can I add another dependency from projectA on root" is "no, you're out of luck there, it'd create a circular dependency and that's not allowed".
The dependencies I'd try are:
In both module A and module B:
dependencies {
implementation 'com.google.guava:guava:23.0'
implementation group: 'com.google.code.gson', name: 'gson', version: '2.8.2'
Then in Module B, you do:
implementation project(':projectA')
Then in root, you depend on both A and B.

Your modules (A and B) are not correctly setup as child modules of the root project.
In your base folder, create if necessary the settings.gradle file, and add the child modules definition:
root/settings.gradle
include 'projectA', 'projectB'
The build.gradle file of projectB is ok as it is, then you need to remove the root/projectB/settings.gradle file; child-modules and their locations are specified in the parent build file.

Transitive file dependencies in gradle

I would like to control which of my dependencies in a multi-project Java build are transitive. My current solution is to set up an "export" configuration in the root project:
allprojects {
configurations {
export {
description = 'Exported classpath'
}
compile {
extendsFrom export
}
}
}
Project A has multiple file dependencies:
dependencies {
compile files('A.jar', 'B.jar')
export files('C.jar')
}
Project B has a dependency on project A, but only C.jar should be on the classpath for compilation, so add:
dependencies {
export project(path: ':A', configuration:'export')
}
This produces the desired results, A.jar and B.jar are not on the class path, but C.jar is on the classpath for compilation.
I am unsure if this is "gradle" way of doing things. To configure transitivity, I would rather specify an attribute or a configuration closure to the dependency entries in project A, instead of using a different "export" configuration.
Is this possible for file dependencies, or is there another way to achieve this?

If I understand your scenario correctly, then yes it's easy to do this. Just add an options closure to the end of the dependency declaration to prevent transitive dependencies (I've changed A,B,C .jar to X,Y,Z because I'm guessing they don't coincide with projects A and B):
// Project A build.gradle
dependencies {
compile(files('X.jar', 'Y.jar')) { transitive = false }
export files('Z.jar')
}
Which would prevent X.jar and Y.jar from being added to the classpath for project B.
Alternatively, and I don't know how well this would work for you and don't really recommend it (just want you to know of the possibilities) you could do this in project B's build.gradle:
configurations.compile.dependencies.find { it.name == "A.jar" }.exclude(jar: it)
configurations.compile.dependencies.find { it.name == "B.jar" }.exclude(jar: it)
Hope that helps.