ben-manes / gradle-versions-plugin

Gradle plugin to discover dependency updates
Apache License 2.0
3.82k stars 199 forks source link

support for `targetConfiguration` dependencies #794

Closed lenntt closed 11 months ago

lenntt commented 11 months ago

I have custom ivy dependencies defined as following

dependencies {
    implementation 'com.myorg:mything:20230711122617.1+', {
        targetConfiguration = "compile"
    }
    // alternatively, more according to the current gradle docs:
    implementation group: 'com.myorg,
        name: 'mything',
        version: '20230711122617.1+',
        configuration: "compile"
}

When I run a ./gradlew dependencyUpdates --info -Drevision=integration Then these dependencies are in the "Failed to determine the latest version for the following dependencies (use --info for details):"-list.

When running with --info, I get a similar error as if I would do a gradle build without having the targetConfiguration there. Therefore, (Disclaimer: I don't understand configurations very well, my setup could be wrong, but) I have the impression the targetConguration is being ignored.

The exception that is the cause of unresolved state: org.gradle.internal.resolve.ModuleVersionResolveException: Could not resolve com.myorg:mything:+.
Required by:
    project :
Caused by: org.gradle.internal.component.NoMatchingConfigurationSelectionException: No matching configuration of com.myorg:mything:20230719152614.1 was found. The consumer was configured to find a runtime of a library compatible with Java 2147483647, packaged as a jar, preferably optimized for standard JVMs, and its dependencies declared externally but:
  - Configuration 'compile':
      - Other compatible attributes:
          - Doesn't say anything about its component category (required a library)
          - Doesn't say anything about how its dependencies are found (required its dependencies declared externally)
          - Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
          - Doesn't say anything about its target Java version (required compatibility with Java 2147483647)
          - Doesn't say anything about its elements (required them packaged as a jar)
          - Doesn't say anything about its usage (required a runtime)
  - Configuration 'openapi':
      - Other compatible attributes:
          - Doesn't say anything about its component category (required a library)
          - Doesn't say anything about how its dependencies are found (required its dependencies declared externally)
          - Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
          - Doesn't say anything about its target Java version (required compatibility with Java 2147483647)
          - Doesn't say anything about its elements (required them packaged as a jar)
          - Doesn't say anything about its usage (required a runtime)
  - Configuration 'provided':
      - Other compatible attributes:
          - Doesn't say anything about its component category (required a library)
          - Doesn't say anything about how its dependencies are found (required its dependencies declared externally)
          - Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
          - Doesn't say anything about its target Java version (required compatibility with Java 2147483647)
          - Doesn't say anything about its elements (required them packaged as a jar)
          - Doesn't say anything about its usage (required a runtime)
  - Configuration 'test':
      - Other compatible attributes:
          - Doesn't say anything about its component category (required a library)
          - Doesn't say anything about how its dependencies are found (required its dependencies declared externally)
          - Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
          - Doesn't say anything about its target Java version (required compatibility with Java 2147483647)
          - Doesn't say anything about its elements (required them packaged as a jar)
          - Doesn't say anything about its usage (required a runtime)
    at org.gradle.internal.component.model.AttributeConfigurationSelector.selectVariantsUsingAttributeMatching(AttributeConfigurationSelector.java:113)
    at org.gradle.internal.component.model.AttributeConfigurationSelector.selectVariantsUsingAttributeMatching(AttributeConfigurationSelector.java:51)
    at org.gradle.internal.component.model.LocalComponentDependencyMetadata.selectVariants(LocalComponentDependencyMetadata.java:149)

I wish I had an reproducable case, but the dependencies are internal. If this really is an issue with the plugin, maybe someone else can provide this.

ben-manes commented 11 months ago

Maybe you could help us improve our ivy testing and support. We don't have any tests for it and it seems to only be used by company internal repositories. We have a local maven repository but not an ivy one, so if you could make fake dependencies to prove it out that would help a lot! In fact the only other ivy user we've seen is #573 (2021) and this plugin is 11 years old. I don't have any knowledge of ivy.

Gradle 1.0 was built on top of Ivy so this plugin originally applied the version latest.release a clone of the configuration to generate a report. Later on Gradle wrote their own dependency resolution and management logic, so that switched to + with resolution rules. Nowadays Gradle publishes its own module metadata for multi-platform resolution (android, kotlin), so there are various attributes we try to retain for compatibility.

Since we let Gradle do the resolution it's unclear if the issue is Gradle's or ours (if the dependency resolves in a compile then I presume it is ours). I think if you could get some various ivy tests in place then it's something we can try to debug.

lenntt commented 11 months ago

Thanks for the help and invitation, but I'm not in such a position right now.

To make it a bit more complete, here's a matching ivy.xml

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="http://ivyrep.jayasoft.org/ivy-doc.xsl"?>
<ivy-module version="2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://ant.apache.org/ivy/schemas/ivy.xsd">
    <info organisation="com.myorg" module="mything" branch="100.0" revision="20230711122617.1" status="integration" publication="20230711122617">
        <ivyauthor name="the team"/>
        <description>my thing</description>
    </info>
    <configurations>
        <conf name="compile"/>
        <conf name="test" extends="compile"/>
        <conf name="provided" visibility="private"/>
        <conf name="openapi"/>
    </configurations>

    <dependencies defaultconfmapping="*->#">
        <dependency org="io.swagger.core.v3" name="swagger-annotations" conf="compile->default" rev="2.1.10" branch="100.0"/>
    </dependencies>

</ivy-module>
lenntt commented 11 months ago

I digged a bit deeper, I still don't understand why, but it seems to be fixed when I added a <conf name="default" extends="compile"/> to the ivy.xml.

I assume (?) this has little to do with this plugin (so will close this issue), hope it helps someone else in the future (as I found the gradle exception hard to understand and action on)