How to create a company specific parent dependency file which can be used across company specific gradle initiated projects
Sample libraries which I want to share across projects
dependencies {
// logging
implementation group: 'org.slf4j', name: 'slf4j-api', version: '1.7.30'
implementation group: 'org.slf4j', name: 'log4j-over-slf4j', version: '1.7.30'
// elasticsearch
implementation group: 'org.elasticsearch', name: 'elasticsearch', version: '7.13.2'
implementation group: 'org.elasticsearch.client', name: 'elasticsearch-rest-high-level-client', version: '7.13.2'
}
To add a dependency to your project, specify a dependency configuration such as implementation in the dependencies block of your module's build.gradle file.
In most cases, a project relies on reusable functionality in the form of libraries or is broken up into individual components to compose a modularized system. Dependency management is a technique for declaring, resolving and using dependencies required by the project in an automated fashion.
What is buildSrc. buildSrc is a directory at the Gradle project root, which can contain our build logic. This allows us to use the Kotlin DSL to write our custom build code with very little configuration and share this logic across the whole project.
The subproject producer defines a task named buildInfo that generates a properties file containing build information e.g. the project version. You can then map the task provider to its output file and Gradle will automatically establish a task dependency. Example 2.
It depends on what is the goal of the parent POM? If it's only for the consolidation dependency versions, you can use a version catalog. A version catalog is a list of dependencies, represented as dependency coordinates, that a user can pick from when declaring dependencies in a build script.
settings.gradle
enableFeaturePreview('VERSION_CATALOGS')
dependencyResolutionManagement {
versionCatalogs {
libs {
// logging
alias('slf4j-api').to('org.slf4j:slf4j-api:1.7.30')
alias('log4j-over-slf4j').to('org.slf4j:log4j-over-slf4j:1.7.30')
// elasticsearch
alias('elasticsearch').to('org.elasticsearch:elasticsearch:7.13.2')
alias('elasticsearch-client').to('org.elasticsearch.client:elasticsearch-rest-high-level-client:7.13.2')
alias('elasticsearch-rest').to('org.elasticsearch.client:elasticsearch-rest-client:7.13.2')
}
}
}
build.gradle
dependencies {
// logging
implementation libs.slf4j.api
implementation libs.log4j.over.slf4j
// elasticsearch
implementation libs.elasticsearch
implementation libs.elasticsearch.client
implementation libs.elasticsearch.rest
}
You can create a separate Gradle project which maintains a version catalog for the whole company. That project then publishes the version catalog to a company-specific repository (like Artifactory). Other company projects can then fetch and use the published version catalog.
Version catalogs can not only be used in normal project dependency declarations but also in plugin dependency declarations.
Important note: as of this writing, this central declaration of dependencies feature is still incubating (in the latest Gradle version 7.3.2). See also the warning on this Gradle docs section.
Below are two complete sample projects:
mycompany-catalog
is the project that maintains and publishes the version catalog.mycompany-app
is some application that uses the published version catalog.I’ve tested this setup with Gradle 7.3.2. For simplicity and self-containedness, I use a local Maven repository.
mycompany-catalog
ProjectYou can publish the version catalog as follows:./gradlew publish
See also the Gradle docs on:
version-catalog
pluginsettings.gradle
enableFeaturePreview('VERSION_CATALOGS')
rootProject.name = 'mycompany-catalog'
build.gradle
plugins {
id 'version-catalog'
id 'maven-publish'
}
// the coordinates of the published catalog
group = 'com.mycompany'
version = 0.42
catalog {
versionCatalog {
// logging
alias('slf4j-api').to('org.slf4j:slf4j-api:1.7.30')
alias('log4j-over-slf4j').to('org.slf4j:log4j-over-slf4j:1.7.30')
// elasticsearch
alias('elasticsearch').to('org.elasticsearch:elasticsearch:7.13.2')
alias('elasticsearch-rest-high-level-client').to(
'org.elasticsearch.client:elasticsearch-rest-high-level-client:7.13.2')
}
}
publishing {
publications {
maven(MavenPublication) {
from components.versionCatalog
}
}
repositories {
// the company-internal repo to which we publish the version catalog
maven {
url = 'file:///tmp/mycompany-repo'
}
}
}
mycompany-app
ProjectYou can check that this works as expected using something like:./gradlew dependencies --configuration runtimeClasspath
See also the Gradle docs on importing a published catalog.
settings.gradle
enableFeaturePreview('VERSION_CATALOGS')
rootProject.name = 'mycompany-app'
dependencyResolutionManagement {
repositories {
// the same company-internal repo (to which we published the version
// catalog in the other project)
maven {
url = 'file:///tmp/mycompany-repo'
}
// a repository from which the external dependencies are fetched
mavenCentral()
}
versionCatalogs {
libs {
// our published catalog
from('com.mycompany:mycompany-catalog:0.42')
}
}
}
build.gradle
plugins {
id 'java'
}
dependencies {
// logging
implementation(libs.slf4j.api)
implementation(libs.log4j.over.slf4j)
// elasticsearch
implementation(libs.elasticsearch)
implementation(libs.elasticsearch.rest.high.level.client)
}
// …
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With