Home > OS >  How to create a company specific parent dependency in gradle
How to create a company specific parent dependency in gradle

Time:12-22

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'
}

CodePudding user response:

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
}

CodePudding user response:

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.

Sample Projects

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 Project

You can publish the version catalog as follows:
./gradlew publish

See also the Gradle docs on:

settings.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 Project

You 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)
}

// …
  • Related