https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# dependency-management
s
This message was deleted.
🤯 1
s
Given a 
build.gradle
that looks like:
Copy code
plugins {
    id 'java-library'
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'io.netty:netty-tcnative-boringssl-static:2.0.58.Final'
    implementation 'io.netty:netty-tcnative-boringssl-static:2.0.58.Final:linux-x86_64'
    implementation 'io.netty:netty-tcnative-boringssl-static:2.0.58.Final:osx-aarch_64'
    implementation 'io.netty:netty-tcnative-boringssl-static:2.0.58.Final:osx-x86_64'
}

println "Classpath = ${sourceSets.main.compileClasspath.asPath}"
The 
dependencies
task lists:
Copy code
implementation - Implementation dependencies for the 'main' feature. (n)
+--- io.netty:netty-tcnative-boringssl-static:2.0.58.Final (n)
+--- io.netty:netty-tcnative-boringssl-static:2.0.58.Final (n)
+--- io.netty:netty-tcnative-boringssl-static:2.0.58.Final (n)
\--- io.netty:netty-tcnative-boringssl-static:2.0.58.Final (n)
Whereas the classpath that’s printed clearly contains each of the resolved jars.
The entry for the classpath appear to be added as a 
CalculatedValue
in the 
RepositoryChainArtifactResolver
here
But subsequently, the information required to recalculate the complete dependency graph, including for items that differ by classifier, appears to be discarded.
Am I missing something obvious?
a
I would guess that Gradle is converting the classifier into a variant attribute, but I have no idea where that might happen. Can you link to the code that's resolving the dependencies? It would be cool to look at. I'm interested because an independent Gradle-compatible resolver would be really helpful for non-Gradle projects to fetch Kotlin Multiplatform projects without needing to add the 
-jvm
suffix.
s
That requirement is one of the many that are encouraging me to do this work 🙂 The code is all here: https://github.com/shs96c/rules_jvm_external/tree/experimental-new-resolver/privat[…]s/java/com/github/bazelbuild/rules_jvm_external/resolver/gradle
thank you 1
e
IMO I don't think that capturing the textual output is a great approach
s
If you want to play with it, clone the repo and make sure you have bazelisk installed. Then just 
bazel run private/tools/java/com/github/bazelbuild/rules_jvm_external/resolver/cmd:Main -- com.google.guava:guava:32.1.2-jre
(or similar)
The output is a lock file for 
rules_jvm_external
, and the error handling is (ummm…) not great, but the idea is sound.
The list of flags you can pass in are all here, though (as you can see) there aren’t docs
e
oh so you're not actually using the 
dependencies
task but re-implementing it yourself? not sure why you'd use the output of it as an example above then
s
Give me a moment, and I’ll make the Gradle resolver the default 🙂
@ephemient to demonstrate that the problem isn’t to do with the extracted resolver, but from gradle itself
If I can figure out how to get the information in a gradle build file, I can make it work in the extracted version
(
HEAD
of that branch now makes the gradle resolver the default one)
e
it's there in the build scan, isn't it? the problem is just that the 
dependencies
renderer doesn't output literally everything
s
I’m not sure: I don’t use the build scan feature
But if the scan has it, that’s good news 🙂 It shows the information is available somewhere
Well, that’s a blow. Running the 
dependencies
task and looking at the scan doesn’t show the different coordinates. It just shows the same collapsed set we see on the command line
2 Views
Open in Slack
PreviousNext
Powered by