Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resolve dynamic deps versions in gradle #15359

Closed
simPod opened this issue Apr 28, 2022 · 8 comments · Fixed by #19127
Closed

Resolve dynamic deps versions in gradle #15359

simPod opened this issue Apr 28, 2022 · 8 comments · Fixed by #19127
Labels
manager:gradle Gradle package manager status:requirements Full requirements are not yet known, so implementation should not be started type:feature Feature (new functionality)

Comments

@simPod
Copy link
Contributor

simPod commented Apr 28, 2022

What would you like Renovate to be able to do?

In build.gradle I do this:

apply from: rootProject.file('gradle/dependencies.gradle')

dependencies {
    annotationProcessor dep.log4jCore
}

gradle/dependencies.gradle:

def versions = [
    log4j                  : '2.17.+',
]

ext.dep = [
    log4jCore              : "org.apache.logging.log4j:log4j-core:$versions.log4j",
]

I'd like Renovate bot to be able to pick log4j version and update it automatically.

Or is there another way to declare deps version in similar manner that Renovate supports?

Is this a feature you are interested in implementing yourself?

No

@simPod simPod added priority-5-triage status:requirements Full requirements are not yet known, so implementation should not be started type:feature Feature (new functionality) labels Apr 28, 2022
@viceice
Copy link
Member

viceice commented Apr 28, 2022

I think you should prefer gadle versions catalog, which is already supported by renovate

https://docs.gradle.org/current/userguide/platforms.html#sub::toml-dependencies-format

@viceice viceice added the manager:gradle Gradle package manager label Apr 28, 2022
@rarkins
Copy link
Collaborator

rarkins commented Apr 28, 2022

Is there a long term reason to use gradle this way instead of v7's central dependencies file?

@simPod
Copy link
Contributor Author

simPod commented Apr 28, 2022

@simPod
Copy link
Contributor Author

simPod commented Apr 29, 2022

@viceice Does it have to be in toml? I have implemented it in groovy and Renovate onboarding says:

* `Failed to look up dependency log4j-core:org.apache.logging.log4j`

for

dependencyResolutionManagement {
    repositories {
        mavenCentral()
    }

    versionCatalogs {
        libs {
            def log4j = '2.17.+'

            library('log4j-core', 'org.apache.logging.log4j', 'log4j-core').version(log4j)
        }
    }
}

@viceice
Copy link
Member

viceice commented Apr 29, 2022

i think we only support the toml file.

@simPod
Copy link
Contributor Author

simPod commented Apr 29, 2022

Are there any plans to support Groovy or Kotlin since they're the main languages people use for Gradle definitions?

@rarkins
Copy link
Collaborator

rarkins commented Apr 29, 2022

In short: maybe not. We certainly don't want to have to execute kotlin or groovy code just to work out what dependencies you're using when there's a simpler alternative having toml

@simPod
Copy link
Contributor Author

simPod commented Apr 29, 2022

Understand, will try to move to toml then. Having Renovate working is more worth than using common language/format.
BTW not sure if I overlooked it but there's not much about it in docs. E.g. Having "supports only TOML" mention might help new users.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
manager:gradle Gradle package manager status:requirements Full requirements are not yet known, so implementation should not be started type:feature Feature (new functionality)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants