dependency-management
  • e

    Emmanuel Guerin

    10/06/2022, 7:19 PM
    Hello. I'm trying out artifact transformation on a dependency between 2 projects. And I can't make it work. I've tried to strip out everything I can into this:https://github.com/emmanuelguerin/artifact-transform-issue Can you help me find what I do wrong? When calling the task
    :sub:resolveSimple
    that directly retrieves an artifact from the root project through a project dependency with the appropriate attributes, everything works. When calling the task
    :sub:resolveTransform
    that uses a configuration with a different value for an attribute, Gradle fails to find the declared transformation.
  • Mattia

    Mattia

    10/08/2022, 9:01 AM
    Hello guys. I have two subprojects A and B, where A depends on
    project(":B")
    . They are published to a maven repo. Depending on some global configuration flag, the artifact ID might be published with a suffix. e.g.
    G:A-suffix:1.0
    and
    G:B-suffix:1.0
    . They either both have the suffix or not. When I use the suffix however, the published metadata for
    A
    (pom, .module) references a dependency to
    B
    and not
    B-suffix
    . Is there a way to fix this from B, when I know we are in suffix mode? I can’t change the project name of course.
  • s

    Steven Zeck

    10/12/2022, 3:14 PM
    Hi all. We are trying to use the TOML version catalog in an Android library project that should be embeddable in a parent project on a local folder (as a Git submodule). But the parent project doesn't recognize the TOML of the child project, as it errors out with
    Unresolved reference: libs
    in the child project's
    build.gradle.kts
    files. If we copy/paste the toml file from the child project into the parent project, it works, but I would think that shouldn't be necessary. Thoughts? -Parent -gradle/libs.versions.toml (this fixes it, but shouldn't be necessary) --Child (as git submodule) ---build.gradle.kts ---settings.gradle.kts ---gradle/libs.versions.toml ----child/project1 -----build.gradle.kts (errors here)
  • a

    Alexander Gherschon

    10/14/2022, 8:59 AM
    Hello, I'm using
    build-logic
    for covention plugins and it works perfectly! I am trying now to build a new Gradle Plugin to generate some code, but I need to share an annotation class between the
    build-logic
    gradle project and its container (main) gradle project as the generated classes in those modules need the dependency to the same annotation. So the question here is, how do you share code between the
    build-logic
    project and the its container (main) project? 🤔
  • Brian Stewart

    Brian Stewart

    10/17/2022, 11:23 PM
    Hi there, I’m looking for some direction on the best way to configure two separate WAR artifacts on a single subproject, but using different sets of libraries included. The idea is, the two artifacts have mostly the same dependencies, but there are two configurations (
    cloud
    and
    tomcatShared
    ) that are unique to one or the other. These configurations should participate in dependency resolution with the main
    runtimeClasspath
    configuration, so there are not mismatched dependency versions between
    runtimeClasspath
    and these extra configurations. Additionally, the second WAR artifact should exclude all dependencies that are unique to the
    tomcatShared
    configuration. How can I exclude the dependencies unique to the
    tomcatShared
    configuration from the
    cloudWar
    artifact? Or is there a better way to set this up? Shortly: •
    main.war
    includes
    tomcatShared
    configuration •
    cloud.war
    includes
    cloud
    configuration, excludes
    tomcatShared
    unique (compared to
    runtimeClasspath
    ) dependencies (declared and transitive) Here is what I have currently (after much experimentation):
    plugins {
        id 'java'
        id 'war'
    }
    
    configurations {
        cloud.extendsFrom runtimeOnly
        tomcatShared.extendsFrom runtimeOnly
    }
    
    dependencies {
        cloud project(':cloud-config')
        cloud '...'
    
        tomcatShared 'org.glassfish.jaxb:jaxb-runtime'
        tomcatShared '...'
    
        // ...other implementation/runtimeOnly dependencies
    }
    
    war {
        archiveFileName = 'main.war'
        classpath configurations.tomcatShared
    }
    
    tasks.register('cloudWar', War) {
        archiveFileName = 'cloud.war'
    
        classpath configurations.cloud
    
        // Need a way to exclude the dependencies unique to the tomcatShared configuration
    }
  • s

    Sergey Chelombitko

    10/19/2022, 8:36 AM
    Is it possible to apply a constraint to a plugin's transitive dependencies if the plugin is applied via plugins DSL?
  • k

    kevinm-m

    10/20/2022, 11:17 PM
    Hi! How come there is no
    file()
    method to create a
    ComponentSelector
    in the DependencySubstitutions interface? Maybe I’m just being shortsighted here, but this seems like something simple enough to add. Furthermore, we can easily declare file dependencies within the project. I would expect a
    FileComponentSelector
    to simply provide the same result as
    dependencies.main.file("foobar")
    Is this an intentional omission or am I missing the intended way to do something like the following.
    configurations { main }
     configurations.main.resolutionStrategy.dependencySubstitution {
       // Substitute module dependency with a file dependency
       substitute module('<http://my.org:api:2.0|my.org:api:2.0>') using file(project.layout.buildDirectory().file("$myInstallDir/lib/api-2.0.jar"))
     }
    Obviously, my intention here is to expand this such that it replaces all dependencies from a certain group with anything locally installed.
  • Martin

    Martin

    10/21/2022, 2:45 PM
    Is it ok to have cycles in projects dependencies as long as the configurations and the task producing the artifacts do not have cycles? moduleA/build.gradle.kts:
    dependencies {
      fooConfiguration(project(":moduleB"))
    }
    moduleB/build.gradle.kts:
    dependencies {
      barConfiguration(project(":moduleA"))
    }
    Or am I going to break stuff doing this?
  • b

    Ben Madore

    10/21/2022, 3:37 PM
    anyone happen to have written a script to convert a Maven BOM into a toml catalog file by any chance 😄 since say, spring boot doesn’t yet a catalog for their Spring Boot Dependencies, thought it would be nice to convert their bom into a catalog to get the typesafe accessors. wanted to check if anyone else had already created / knew of such a script before reinventing the wheel
  • v

    Vojtech Hrdina

    10/26/2022, 6:46 AM
    Hi, is there any way how to use https://docs.gradle.org/current/javadoc/org/gradle/vcs/SourceControl.html with private repositories? SSH authentication issue is open for more than 3 years: https://github.com/gradle/gradle/issues/8245
  • Lars Kaulen

    Lars Kaulen

    10/26/2022, 7:51 PM
    Hi, I declare a
    gradle/libs.versions.toml
    file with the following content:
    [versions]
    spring-boot = "2.7.5"
    
    [plugins]
    spring-boot = { id = "org.springframework.boot", version.ref = "spring-boot" }
    Then in
    buildSrc/settings.gradle.kts
    I specify:
    dependencyResolutionManagement {
        versionCatalogs {
            create("libs") {
                from(files("../gradle/libs.versions.toml"))
            }
        }
    }
    And in
    buildSrc/src/main/groovy/example.java-conventions.gradle
    I add the following:
    plugins {
        id "java"
        alias(libs.plugins.spring.boot)
    }
    I get the following exception (without the
    alias(...)
    everything works):
    Could not compile script '...\buildSrc\src\main\groovy\example.java-conventions.gradle'.
    > startup failed:
      script '...\buildSrc\src\main\groovy\example.java-conventions.gradle': 3: only alias(libs.plugins.someAlias) plugin identifiers where `libs` is a valid version catalog
      
      See <https://docs.gradle.org/7.5.1/userguide/plugins.html#sec:plugins_block> for information on the plugins {} block
      
       @ line 3, column 5.
             alias(libs.plugins.spring.boot)
             ^
      
      1 error
    Does anybody know, what this wants to tell me? Looks pretty comparable to the example in https://docs.gradle.org/current/userguide/platforms.html#sec:plugins to me
  • p

    Petri Kivikangas

    10/28/2022, 11:00 AM
    Is it possible to define and use plugin bundles? I.e., something like this:
    [bundles]
    defaultPlugins = ["java"]
    
    [plugins]
    java = { id = "java" }
    and
    plugins {
      alias(libs.bundles.defaultPlugins)
    }
  • н

    Николай Ильминский

    10/28/2022, 1:35 PM
    Hey guys. Is it me or gradle's platform dependencies don't work in conjunction with the core "jvm test suite" plugin? A minimal code sample to reproduce this (groovy dsl, gradle version 7.5.1):
    plugins {
        id 'java'
    }
    repositories {
        mavenCentral()
    }
    dependencies {
        implementation platform("org.testcontainers:testcontainers-bom:1.17.4")
    }
    testing {
        suites {
            integrationTest(JvmTestSuite) {
                dependencies {
                    implementation project
                    implementation "org.testcontainers:kafka"     // <- I omitted version
                }
            }
        }
    }
    getting this:
    Could not find org.testcontainers:kafka:.
    Required by:
        project :
    That error message means it doesn't take into account
    implementation platform("org.testcontainers:testcontainers-bom:1.17.4")
    declared at top level
  • tony

    tony

    11/01/2022, 12:26 PM
    is anyone aware of planned work that would make dependency catalog references navigable from build.gradle (Groovy DSL) files in Intellij IDEA? Right now you can only navigate within Kotlin DSL files.
  • Pierre Ayfri

    Pierre Ayfri

    11/03/2022, 3:54 AM
    Hi, I have a complex situation of circular dependencies and I need help on how to fix it in some way. I'm creating Kotlin typings for a multi npm package TypeScript library, with one gradle module per npm package. There is the
    core
    package which is requiring the
    utils
    package, but the
    utils
    package uses some types from the
    core
    package, because in TypeScript you have a
    import type
    statement that lets you import types from another package, without having to declare this package as a dependency. But for my case, what should I do ? As my Kotlin typings must be equal to the TS typings, and it would be weird to duplicate the imported types (with
    import type
    ) as a solution 🤔 So, what should I do ?
  • d

    Dave562

    11/03/2022, 9:23 AM
    Hello, with groovy changing its GAV coordinates with version 4. I have problem resolving it correctly with libraries depending on old GAV (geb-core in my case) I have this configuration:
    configurations.configureEach {
        resolutionStrategy {
            capabilitiesResolution.all {
                if (this.capability.group == "org.codehaus.groovy" || this.capability.group == "org.codehaus.groovy") {
                    this.selectHighestVersion()
                }
            }
        }
    }
    dependencies {
        components.all(GroovyVersionAlign::class.java)
        testImplementation("org.apache.groovy:groovy-all:4.0.6")
        testImplementation("org.junit.jupiter:junit-jupiter:5.8.2")
        testImplementation("org.gebish:geb-core:6.0")
    }
    class GroovyVersionAlign : ComponentMetadataRule {
        override fun execute(context: ComponentMetadataContext) = context.details.run {
            if (id.group.equals("org.apache.groovy") || id.group.equals("org.codehaus.groovy")) {
                belongsTo("org.apache.groovy:groovy-virtual-platform:${id.version}")
            }
        }
    }
    but I am getting this exception when compiling tests even on test project generated with gradle init library type, where is only one simple unit test without actually using geb.
    org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':lib:compileTestGroovy'.
            at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.lambda$executeIfValid$1(ExecuteActionsTaskExecuter.java:142)
            at org.gradle.internal.Try$Failure.ifSuccessfulOrElse(Try.java:282)
            at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeIfValid(ExecuteActionsTaskExecuter.java:140)
            at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:128)
            at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:77)
            at org.gradle.api.internal.tasks.execution.FinalizePropertiesTaskExecuter.execute(FinalizePropertiesTaskExecuter.java:46)
            at org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter.execute(ResolveTaskExecutionModeExecuter.java:51)
            at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:57)
            at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:56)
            at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:36)
            at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77)
            at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55)
            at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52)
            at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:204)
            at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:199)
            at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66)
            at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59)
            at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:157)
            at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59)
            at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:53)
            at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:73)
            at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:52)
            at org.gradle.execution.plan.LocalTaskNodeExecutor.execute(LocalTaskNodeExecutor.java:69)
            at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:327)
            at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:314)
            at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:307)
            at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:293)
            at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.execute(DefaultPlanExecutor.java:417)
            at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.run(DefaultPlanExecutor.java:339)
            at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
            at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
    Caused by: java.lang.ExceptionInInitializerError
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at org.gradle.api.internal.classloading.GroovySystemLoaderFactory.getGroovyVersion(GroovySystemLoaderFactory.java:58)
            at org.gradle.api.internal.classloading.GroovySystemLoaderFactory.createClassInfoCleaningLoader(GroovySystemLoaderFactory.java:51)
            at org.gradle.api.internal.classloading.GroovySystemLoaderFactory.forClassLoader(GroovySystemLoaderFactory.java:34)
            at org.gradle.api.internal.tasks.compile.ApiGroovyCompiler.execute(ApiGroovyCompiler.java:188)
            at org.gradle.api.internal.tasks.compile.ApiGroovyCompiler.execute(ApiGroovyCompiler.java:64)
            at org.gradle.api.internal.tasks.compile.GroovyCompilerFactory$DaemonSideCompiler.execute(GroovyCompilerFactory.java:97)
            at org.gradle.api.internal.tasks.compile.GroovyCompilerFactory$DaemonSideCompiler.execute(GroovyCompilerFactory.java:76)
            at org.gradle.api.internal.tasks.compile.daemon.AbstractDaemonCompiler$CompilerWorkAction.execute(AbstractDaemonCompiler.java:135)
            at org.gradle.workers.internal.DefaultWorkerServer.execute(DefaultWorkerServer.java:63)
            at org.gradle.workers.internal.AbstractClassLoaderWorker$1.create(AbstractClassLoaderWorker.java:49)
            at org.gradle.workers.internal.AbstractClassLoaderWorker$1.create(AbstractClassLoaderWorker.java:43)
            at org.gradle.internal.classloader.ClassLoaderUtils.executeInClassloader(ClassLoaderUtils.java:100)
            at org.gradle.workers.internal.AbstractClassLoaderWorker.executeInClassLoader(AbstractClassLoaderWorker.java:43)
            at org.gradle.workers.internal.IsolatedClassloaderWorker.run(IsolatedClassloaderWorker.java:49)
            at org.gradle.workers.internal.IsolatedClassloaderWorker.run(IsolatedClassloaderWorker.java:30)
            at org.gradle.workers.internal.WorkerDaemonServer.run(WorkerDaemonServer.java:87)
            at org.gradle.workers.internal.WorkerDaemonServer.run(WorkerDaemonServer.java:56)
            at org.gradle.process.internal.worker.request.WorkerAction$1.call(WorkerAction.java:138)
            at org.gradle.process.internal.worker.child.WorkerLogEventListener.withWorkerLoggingProtocol(WorkerLogEventListener.java:41)
            at org.gradle.process.internal.worker.request.WorkerAction.run(WorkerAction.java:135)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
            at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
            at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:182)
            at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:164)
            at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:414)
            at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
            at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
    Caused by: groovy.lang.GroovyRuntimeException: Conflicting module versions. Module [groovy-macro is loaded in version 4.0.6 and you are trying to load version 3.0.12
            ... 33 more
    I have also tried adding "apache" capability to "codehaus" dependencies like this ("apache" libraries have "codehaus" capability in their metadata already):
    if (id.group.equals("org.apache.groovy") || id.group.equals("org.codehaus.groovy")) {
                belongsTo("org.apache.groovy:groovy-virtual-platform:${id.version}")
                allVariants {
                    withCapabilities {
                        addCapability("org.apache.groovy", id.name, id.version)
                    }
                }
            }
    But id did not work. Any advice how to solve this? Thanks
  • Lars Kaulen

    Lars Kaulen

    11/08/2022, 7:40 AM
    Right now, when I use convention plugins, e.g. in
    buildSrc
    , and I want to apply external plugins in those convention plugins, I need to add them as a dependency to the buildSrc/build.gradle.kts:
    dependencies { implementation("group:artifact:version") }
    with
    group:artifact
    being different from the plugin id (see here, looks like it's the same in any precompiled plugin as described here ). This makes the version catalog plugins notation (e.g.
    alias(libs.plugins.spotbugs)
    ) completely useless when using convention plugins (ignoring https://github.com/gradle/gradle/issues/15383), doesn't it? And also the
    pluginManagement.plugins
    block can't be used in this case either. Anyone knows of a way to do this without the
    dependencies.implementation
    block or an issue that tracks this (couldn't find one)?
  • r

    Ryan Schmitt

    11/08/2022, 5:08 PM
    Suppose I have a library with a transitive dependency that can't be resolved (i.e. the POM file can't be retrieved), but I know I don't need it for anything. How can I ask Gradle to ignore the missing artifact instead of throwing an exception?
  • Jendrik Johannes

    Jendrik Johannes

    11/10/2022, 9:44 AM
    Is there a way to set resolution strategies of a detached configuration that a plugin creates? I don't know how one could do that. If it is not possible, I think this is quite a gap in the context of capability conflict resolution. Because if I register a Metadata Rule to add Capabilities (or if the Capabilities are actually published) these apply globally. And if there is a conflict, I need to define a resolution strategy. Because there is no default strategy for capability conflicts. Concrete issue: • I add the rules from here to an Android project: https://github.com/jjohannes/java-ecosystem-capabilities • I get a conflict for
    lintVitalReportRelease
    > Could not resolve all task dependencies for configuration ':app:detachedConfiguration2'.
       > Could not resolve jakarta.activation:jakarta.activation-api:1.2.1.
         ...
          > Module 'com.sun.activation:javax.activation' has been rejected:
               Cannot select module with conflict on capability 'javax.activation:activation:1.2.0' also provided by [jakarta.activation:jakarta.activation-api:1.2.1(runtime)]
    https://scans.gradle.com/s/suujraume64nw/failure#1 The plugin defines default strategies, using
    configurations.all {}
    , but this does not seem to apply for detached configuration.
  • David Chang

    David Chang

    11/10/2022, 7:12 PM
    Hello, I'm currently using an internal artifactory for our dependencies and we had an outage with it. I'm wondering why does Gradle not fallback gracefully to other repositories in the list? in this case, we had a 502 Bad Gateway when fetching a specific pom.
  • c

    Chris Doré

    11/10/2022, 11:32 PM
    Before I go down the road of prototyping and testing, does anyone know how attributes behave in the context of
    Configuration.extendsFrom
    when attribute values differ between the current config and the extended config? If the current config is resolved, are the attributes from the extended config taken into consideration for the dependencies declared on it?
  • b

    Ben Madore

    11/16/2022, 3:58 PM
    is there a way to find out where a particular constraint is coming from… for instance:
    ./gradlew :mymodule:dependencies
    
    compileClasspath - Compile classpath for source set 'main'.
    \--- org.apache.commons:commons-lang3:3.12.0
    
    ...
    
    runtimeClasspath - Runtime classpath of source set 'main'.
    +--- org.apache.commons:commons-lang3:3.12.0
    \--- org.apache.commons:commons-lang3:{strictly 3.12.0} -> 3.12.0 (c)
    i’m not sure what is introducing that strictly constraint (not a big deal, just want to understand why)
    ./gradlew :mymodule:dependencyInsight --dependency "org.apache.commons:commons-lang3"
    
    org.apache.commons:commons-lang3:3.12.0
      Variant compile:
        | Attribute Name                 | Provided | Requested         |
        |--------------------------------|----------|-------------------|
        | org.gradle.status              | release  |                   |
        | org.gradle.category            | library  | library           |
        | org.gradle.libraryelements     | jar      | classes+resources |
        | org.gradle.usage               | java-api | java-api          |
        | org.gradle.dependency.bundling |          | external          |
        | org.gradle.jvm.environment     |          | standard-jvm      |
        | org.gradle.jvm.version         |          | 17                |
    
    org.apache.commons:commons-lang3:3.12.0
    \--- compileClasspath
  • Javi

    Javi

    11/18/2022, 9:24 AM
    Is it possible to consume fixtures in an implementation configuration in other project? The use case is using the fixtures in a variant which would build a fake app instead of the prod one.
  • p

    Phanindra R

    11/21/2022, 9:41 PM
    We're updating a number of repos to consume centrally managed version catalogs. I'd like to open up a discussion on something, especially with the premise of having to repeat a solution/setup across 100+ repos. Please correct me if I missed something. A random example -
    api importedCatalog.someThirdPartyLibrary
    brings in an older version of
    org.apache.httpcomponents:httpclient
    . In this case
    someThirdPartyLibrary
    works just fine with a newer
    httpclient
    with security patches. It'd be nice to have some control over important transitive dependency versions. Here's a few ways to ensure that with respective pros & cons. Solution 1) Create a Version Catalog and a Platform/BOM from the same source, e.g. Micronaut toml and bom
    a. Import the Catalog and use that for dependencies.
    b. Also apply the bom/platform for the constraints.
    Pros: Works Cons: • Versions come in hardcoded in the bom/platform so cannot use the native version overriding feature in Version Catalog anymore, e.g.
    version('alias', 'version') // in settings.gradle
    • Can be done but there's no native support for publishing a catalog and a platform from the same source. Solution 2) Make sure all important libraries with preferred versions are listed in in the catalog and do the below
    dependencies{
      api importedCatalog.someLibrary1
      api importedCatalog.someLibrary2
      // more..
    
      constraints{
        project.extensions.findByType(VersionCatalogsExtension).find('importedCatalog').get().libraryAliases.each {libraryAlias ->
          api versionCatalog.findLibrary(libraryAlias).get()
        }
    
        importedCatalog.bundles.reallyImportantLibraries.get().each { library ->
          api("${library}!!") // avoid unintended upgrades
        }
      }
    }
    Pros: Works Cons: Too clumsy to repeat in all repositories. Solution 3) To be Supported
    dependencies{
      api importedCatalog.someLibrary1
      api importedCatalog.someLibrary2
      // more..
    
      constraints{
        api importedCatalog // or preferably "api importedCatalog.libraries.filter{..}" // all [libraries] entries will be used . We could also go for a potentially autogenerated bundle: importedCatalog.bundles._allLibraries 
        api importedCatalog.bundles.reallyImportantLibraries {strictly true} // all entries from the bundle will be applied with a strictly constraint. This is for avoiding unintended upgrades.
      }
    }
    Pros: All will come from the catalog. No need for a complementing platform artifact. The version overriding in the settings.gradle will continue to work even for the transitive libraries due to the constraints. Cons: No support exists yet.-------------------------------------------- Solutions (1) and (2) work fine in the context of a single repo but the Solution (3) could be efficient and more convenient at scale. My question - Is Solution (3) something Gradle would be interested in exploring or is there a way to do this already?
  • i

    Igor Wojda

    11/22/2022, 12:14 PM
    For declaration like this
    androidx-compose-ui-tooling-preview = { module = "androidx.compose.ui:ui-tooling-preview" }
    in the
    libs.versions.toml
    file - how library version is determined without
    version.ref
    attribute?
  • Gabriel Feo

    Gabriel Feo

    11/23/2022, 3:59 PM
    I'm looking to centralize repositories setup in our composite build, but it seems
    dependencyResolutionManagement
    isn't enough for included builds. Do I need to define repositories in both
    dependencyResolutionManagement
    and
    pluginManagement
    ?
    Could not resolve all files for configuration 'classpath'.
    > Could not find com.android.tools.build:gradle:7.3.1.
      Searched in the following locations:
        - <https://plugins.gradle.org/m2/com/android/tools/build/gradle/7.3.1/gradle-7.3.1.pom>
      If the artifact you are trying to retrieve can be found in the repository but without metadata in 'Maven POM' format, you need to adjust the 'metadataSources { ... }' of the repository declaration.
      Required by:
          unspecified:unspecified:unspecified > project :settings-plugin-included-build
  • j

    Joffrey Bion

    11/30/2022, 3:28 PM
    I'm sorry I'm quite new in this Slack, so please redirect me if this is the wrong channel. Is there any library to perform Gradle dependency resolution but at runtime (programmatically)? I'm looking for something akin to Aether (a.k.a. Apache Maven Artifact Resolver, now). Something that would allow to specify repositories and download artifacts and their transitive dependencies (ideally also with version conflict resolution, but I guess that might be out of scope)
  • Gabriel Feo

    Gabriel Feo

    11/30/2022, 7:18 PM
    I have a large multi-project build that has long used everything as
    implementation
    , even when part of the public API. In that case, the consumer will also add each dependency required to compile as
    implementation
    . Is there any harm in doing this? Always saw it as only a nuisance, but now I suspect some "caching issues" we're seeing might be caused by this, e,g, failures for unresolved reference, then success after developer nukes Gradle home (yep 👀), as if something should've been recompiled and wasn't