Gradle Version Catalog (Published): How to dynamically set up repository - gradle

I'm not that experienced with Gradle and are currently running into problems when trying to use the new version catalog feature.
Goal:
Using a Gradle 7.4.2 version catalog, managed in a standalone GIT repository and published to private JFrog artifactory, in a second project.
Every project member's artifactory credentials are already available in $HOME/.gradle/gradle.properties (auto-generated by JFrog) and are supposed to be re-used.
Issue:
according to the current Gradle documentation, a published version catalog is supposed to be defined in settings.gradle(.kts) within any project that wants to use the catalog;
inserting that piece of code results in an error because Gradle has no repository definition available for artifact look-up
therefore, adding a repository definition:
// my settings.gradle.kts
rootProject.name = "catalog-consumer"
dependencyResolutionManagement {
val catalogVersion = "0.1.0"
val artifactoryUri = "..."
val catalogGAV = "..."
repositories{
maven {
url = uri("$artifactoryUri")
credentials {
// TODO: how to access user's local gradle.properties for credentials?
username = "$artifactory_user" // key as generated by JFrog
password = "$artifactory_password" // key as generated by JFrog
}
}
}
versionCatalogs {
create("libs") {
from("$catalogGAV")
}
}
}
now, facing the problem that the user's gradle.properties does not seem to be loaded, yet - but hardcoding credentials is not viable :)
Question:
Is the only option to manually check for and load the user's gradle.properties file?
Originally, when reading the documentation, I assumed that the settings file would probably try to look up existing repository definitions from the project's build.gradle.kts, but that wasn't the case either. If I understand it correctly, the settings file is evaluated before everything else, isn't it?
Manually loading the user's config just seems odd to me, therefore, I wanted to ask whether or not I'm missing a mechanism or lifecycle hook that would take care of this. Also possible that I use the version catalog feature incorrectly :D
Any hints very much appreciated!

See the docs here: https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:handling_credentials
Named repository credentials
If you named the repository and add credentials(PasswordCredentials::class)...
// ./settings.gradle.kts
dependencyResolutionManagement {
repositories {
maven {
name = "mySecureRepository"
credentials(PasswordCredentials::class)
// url = uri(<<some repository url>>)
}
}
}
then Gradle will automatically fetch the username/pass from the first found definition:
Using a command line argument
./gradlew build -PmySecureRepositoryUsername=my-username
environment variables prefixed with ORG_GRADLE_PROJECT_ (this is useful for CI/CD)
ORG_GRADLE_PROJECT_mySecureRepositoryUsername=my-username
ORG_GRADLE_PROJECT_mySecureRepositoryPassword=my-password
$GRADLE_USER_HOME/gradle.properties
mySecureRepositoryUsername=my-username
mySecureRepositoryPassword=my-password
gradle.properties in the project root - obviously don't put credentials in your project!
gradle.properties in the Gradle installation directory
Manual providers
If you need to manually set the property names, then you can define your own providers.
// ./settings.gradle.kts
val artifactoryUser = providers.gradleProperty("artifactory_user")
val artifactoryPassword = providers.gradleProperty("artifactory_password")
dependencyResolutionManagement {
repositories {
maven {
name = "mySecureRepository"
credentials {
username = artifactoryUser.get()
password = artifactoryPassword.get()
}
// url = uri(<<some repository url>>)
}
}
}
Again, then Gradle will fetch these properties from either
$GRADLE_USER_HOME/gradle.properties
artifactory_user=my-username
artifactory_password=my-password
or environment variables
ORG_GRADLE_PROJECT_artifactory_user=myUsername
ORG_GRADLE_PROJECT_artifactory_password=my-password

Related

Gradle7 Version Catalog: How to use it with buildSrc?

I am very excited about the incubating Gradle's version catalogs and have been experimenting with it. I’ve found that the information in my gradle/libs.versions.toml is accessible in the build.gradle.kts scripts for my app and utility-lib projects.
However, I am unable to use the content of the toml file for buildSrc/build.gradle.kts or the convention files.
The only way that I could build was to hard-code the dependencies into those files, as I did before the version catalog feature.
In the buildSrc folder, I created a settings.gradle.kts file and inserted the dependencyResolutionManagement code for versionCatalogs, which is pointing to the same file as for my app and utility-lib projects.
Based on the Gradle7 docs, it seems that sharing a version catalog with buildSrc and modules is possible… I’d appreciate a nudge into getting it to work with buildSrc, if possible.
Here is a simple sample project, which I created via gradle init: my-version-catalog
Thank you for your time and help,
Mike
With Gradle 7.3.3, it is possible. Note version catalogs are GA since Gradle 7.4
The code snippet assumes Gradle is at least 7.4, but if you need them prior that version, insert enableFeaturePreview("VERSION_CATALOGS") at the beginning of each settings.gradle.kts.
Using buildSrc
buildSrc/settings.gradle.kts
dependencyResolutionManagement {
versionCatalogs {
create("libs") {
from(files("../gradle/libs.versions.toml"))
}
}
}
buildSrc/build.gradle.kts
dependencies {
implementation(libs.gradleplugin.intellij) // <- the lib reference
}
You can even use the version catalog for plugins
gradle/libs.versions.toml
...
[plugins]
kotlin-jvm = { id = "org.jetbrains.kotlin.jvm", version.ref = "kotlin" }
jetbrains-changelog = { id = "org.jetbrains.changelog", version.ref = "changelog-plugin" }
jetbrains-intellij = { id = "org.jetbrains.intellij", version.ref = "intellij-plugin" }
hierynomus-license = { id = "com.github.hierynomus.license", version.ref = "license-plugin" }
nebula-integtest = { id = "nebula.integtest", version.ref = "nebula-integtest-plugin" }
build.gradle.kts
plugins {
id("java")
alias(libs.plugins.kotlin.jvm)
alias(libs.plugins.nebula.integtest)
alias(libs.plugins.jetbrains.intellij)
alias(libs.plugins.jetbrains.changelog)
alias(libs.plugins.hierynomus.license)
}
Note for accessing the catalog within scripts, please refer to the below section, the trick is the same.
Using convention plugins and included build
In the main project include a the Gradle project that holds the convention plugins.
build.gradle.kts
includeBuild("convention-plugins") // here it's a subfolder
convention-plugins/settings.gradle.kts
dependencyResolutionManagement {
repositories {
gradlePluginPortal()
}
versionCatalogs {
create("libs") {
from(files("../gradle/libs.versions.toml"))
}
}
}
rootProject.name = "convention-plugins"
The trick to enable convention plugins to access the version catalog is split in two part, add an ugly implementation dependency that locate where the version catalog generated classes are located.
libs.javaClass.superclass.protectionDomain.codeSource.location
Then in the convention plugin refer to the libs extension via Project::the.
val libs = the<LibrariesForLibs>()
This is tracked by gradle/gradle#15383.
convention-plugins/build.gradle.kts
plugins {
`kotlin-dsl`
}
dependencies {
implementation(libs.gradleplugin.kotlin.jvm)
// https://github.com/gradle/gradle/issues/15383
implementation(files(libs.javaClass.superclass.protectionDomain.codeSource.location))
}
And in the actual convention plugin
import org.gradle.accessors.dm.LibrariesForLibs
plugins {
id("org.jetbrains.kotlin.jvm")
}
// https://github.com/gradle/gradle/issues/15383
val libs = the<LibrariesForLibs>()
dependencies {
detektPlugins(libs.bundles.kotlinStuff) // access catalog entries
}
The org.gradle.accessors.dm.LibrariesForLibs class is generated by gradle is somewhere in local gradle folder ./gradle/<version>/dependency-accessors/<hash>/classes
Quick note that older IntelliJ IDEA currently (2022.3) reports alias(libs.gradleplugin.thePlugin) as an error in the editor,
although the dependencies are correctly resolved.
This tracked by KTIJ-19369, the ticket indicates this is actually a bug in Gradle Kotlin DSL gradle/gradle#22797, and someone made a simple IntelliJ IDEA plugin to hide this error until resolved.
Brice, it looks like a can of worms to go down that path, particularly for my situation, where I'm trying to use a libs.version.toml file from an android project, but the custom plugin is of course from a java/kotlin project. I tried creating the libs file by hardwiring the path to the toml file in the custom plugin. It might work if both were java projects, but I never tried that since that's not what I'm after. The ideal solution would be for the plugin to use the libs file from the project it is applied to, but it looks like the version catalog needs to be created in the settings file, before you even have access to "Project", so that's why you would have to hardwire the path.
Short answer. No, but there are other techniques for a custom plugin to get project version data from the project it is applied to.

Naming deployed jar file with gradle publish?

We're looking at ditching artifactory and are intending to move to reposilite, because artifactory is just too big and maintenance-heavy for our small team.
However, when using gradle publish to deploy to reposilite, I am unable to get control of the name of the actual jar. The pushed jar is always named project-x.x.x-{build-number}.jar.
I would like to do it the way the artifactory plugin did it, which deployed a properly named snapshot jar (just project-x.x.x-SNAPSHOT.jar), letting subsequent snapshots of the same version overwrite each other, which is a more convenient arrangement for us for several reasons that I won't go into right now.
Long story short, is there any way I can tell gradle publish how to name the deployed jar exactly? Our usual setup currently looks like this:
configure<PublishingExtension> {
publications {
create<MavenPublication>("myproject") {
from(components["java"])
groupId = "our.company.myproject"
artifactId = "myproject"
artifact(sourceJar)
}
}
repositories {
maven {
credentials {
username = $mavenUser
password = $mavenPassword
}
url = uri("http://localhost:8080/snapshots") # while testing
authentication {
create<BasicAuthentication>("basic")
}
}
}
}
There isn't really a problem with that configuration. It works. All I want to do is control the exact name of the jar file being deployed in addition to what I'm doing here, and I can't find a way to do it. The jar that is put to the build/libs directory is named properly, it's just the publication throwing me a curve ball.

How to define Gradle project properties with Kotlin DSL

I'd like to check if two project properties are set and if not, set them to empty values in order to avoid a build failure. These properties are supposed come from ~/.gradle/gradle.properties (if configured).
The goal is to have credentials to a Maven repository in S3 defined in that local file. Every user has to put his own data there, but I want the build to just output a warning and continue if these are not set. Chances are high it will still be successful even without contacting S3.
I have got it running with Groovy DSL, but I am now switching to Kotlin and I just can't get the syntax right.
This is how ~/.gradle/gradle.properties looks like:
s3AccessKeyId=ABCDEFGHIJKLMNOPQRST
s3SecretKey=abcdefghijklmnopqrstuvwxyz1234567890abcd
And here are the relevant sections of the build.gradle.kts
if (!project.hasProperty("s3AccessKeyId") || !project.hasProperty("s3SecretKey")) {
logger.lifecycle("WARNING: s3AccessKeyId and s3SecretKey not set!")
project.extra["s3AccessKeyId"] = ""
project.extra["s3SecretKey"] = ""
}
repositories {
mavenLocal()
maven {
url = uri("s3://maven-repo.mycompany.com.s3.eu-central-1.amazonaws.com/")
credentials(AwsCredentials::class) {
accessKey = project.extra["s3AccessKeyId"].toString()
secretKey = project.extra["s3SecretKey"].toString()
}
}
}
No matter how I write the s3AccessKeyId="" lines, I am always getting the error:
Cannot get property 's3AccessKeyId' on extra properties extension as it does not exist
If all artifacts are found in the local Maven repository, I expect the build to work, even without gradle.properties. Only if some artifact is missing, the build should abort with some "credentials wrong" error.
As I said, it already worked with Groovy.
For that you need to use the properties attibute which is different from the extra like:
project.properties["s3SecretKey"].toString()
And then you need to have in your gradle.properties:
s3AccessKeyId=ABCDEFGHIJKLMNOPQRST
If the value is not there it might return null so you can do:
(project.properties["s3SecretKey"] ?: "default value").toString()
And it should work

Want to configure build.gradle so that artifcatory user and pass are worked in both local and in Jenkins

So basically this is what I want, I want to configure the artifactory server in build.gradle file like
Artifcatory {
Contexturl = ***
Resolve{
Repository {
Repokey = **
Username = $artuser
Password= $artpass
}
}
}
And I have put the artuser and artpass in the gradle.properties file in my local machine. But if I try it in Jenkins it will not be able to find the properties artuser and artpass
So currently I have 2 build.gradle file one for local and one for Jenkins which is not having this artifcatory configuration. But configuring it in the build stage. so is there a way I could use only one build.gradle file so that it will work in both cases
I'd suggest using the credentials plugin on Jenkins to manage credentials, and then pass them as environment variables to gradle. That way, there is no need to put the credentials in clear text on the build server.
If you are using declarative Jenkinsfile, you can pass credentials this way (https://jenkins.io/doc/book/pipeline/jenkinsfile/#usernames-and-passwords):
Jenkinsfile:
pipeline {
...
environment {
AUTH = credentials('artifactory-credentials-id') # as configured in the Jenkins web interface
}
...
}
In build.gradle, you can use pick credentials from either gradle.properties for local builds, and environment variables for Jenkins builds:
artifactory {
contextUrl = "..."
resolve {
repository {
repoKey = "..."
username = hasProperty('artusr') ? project.property('artusr') : System.env["AUTH_USR"]
password = hasProperty('artpass') ? project.property('artpass') : System.env["AUTH_PSW"]
}
For local builds it is then possible to put the credentials in ~/gradle.properties:
artusr=my-artifactory_user
artpass=my-secret-password

Cloning a git repo in a task by providing authentication

I want to clone a private repository in my system. I am able to clone a public repo using:
def myrepo = org.ajoberstar.grgit.Grgit.clone(dir:'', uri:'')
but in case of a private repo, I need to provide credentials to clone. I have gone through this link, but the properties given here like Force, Hardcoded are not available in my gradle. So, I am not able to make use of the properties given here.
The following properties are available for me:
org.ajoberstar.grgit.auth.AuthConfig.FORCE_OPTION
org.ajoberstar.grgit.auth.AuthConfig.USERNAME_OPTION
org.ajoberstar.grgit.auth.AuthConfig.PASSWORD_OPTION
and if I give any value to these, I get error Cannot assign value to final fields
Can anybody help with the authentication part?
I am using dependency org.ajoberstar:grgit:1.3.0.
The link you provided clearly states that system properties need to be used to pass appropriate settings.
So you need to run gradle passing all the properties via command line. Assume this is build.gradle file:
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'org.ajoberstar:grgit:1.3.0'
}
}
task cloneRepo << {
org.ajoberstar.grgit.Grgit.clone(dir: '', uri: '<link to private repo>')
}
Run it with:
gradle cloneRepo -Dorg.ajoberstar.grgit.auth.username=your_username -Dorg.ajoberstar.grgit.auth.password=your_pass -Dorg.ajoberstar.grgit.auth.force=sshagent

Resources