https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
r
The task looks like this
Copy code
fun Configuration.isDeprecated() = this is DeprecatableConfiguration &&
  resolutionAlternatives != null

fun ConfigurationContainer.resolveAll() = this
  .filter { it.isCanBeResolved && !it.isDeprecated() }
  .forEach { it.resolve() }

tasks.register("downloadDependencies") {
  doLast {
    configurations.resolveAll()
    buildscript.configurations.resolveAll()
  }
}
It fails like this:
Copy code
Execution failed for task ':downloadDependencies'.
> Could not resolve all files for configuration ':testRuntimeOnlyDependenciesMetadata'.
   > Could not find org.junit.platform:junit-platform-launcher:.
     Required by:
         project :
Any insights into what's going on there?
c
the error message indicates that no version is specified for that artifact.
r
OK, but there never was; the 
downloadDependencies
task worked fine in gradle 7.6, and I can do a 
./gradlew test
quite happily in gradle 8, so whatever gradle needs to do to actually run the tests it can do.
Which suggests my notion of how to resolve all dependencies in the 
downloadDependencies
task is now broken - but I'm not sure how, so I'm not sure how to fix it.
v
Did you also update Kotlin plugin? Or maybe this is a build that uses embedded Kotlin plugin like when applying 
kotlin-dsl
plugin? Afair the 
...DependenciesMetadata
tasks are added by the Kotlin plugin.
c
perhaps the scope of downloading is too broad - do you need dependencies from 
testRuntimeOnlyDependenciesMetadata'
, for example? If so that configuration will need the junit BOM or otherwise have an artifact version specified.
r
I've been on 
kotlin("jvm") version "1.8.10"
for a couple of weeks
v
r
Ah, thanks. That looks like a sensible upstream bug.
v
But reading that, I wonder it worked before and did not also fail
What you could maybe do is to not resolve the configurations themselves, but instead create an artifact view, set it to lenient, and resolve that. Then it should not fail even if something cannot be resolved.
r
Thanks, that seemed to work:
Copy code
fun ConfigurationContainer.resolveAll() = this
  .filter { it.isCanBeResolved && !it.isDeprecated() }
  .map { it.incoming.artifactView { isLenient = true } }
  .forEach { it.files.files }
👌 1
Hmm... not quite there. To explain, the goal is that a successful run of 
downloadDependencies
should allow gradle to then work offline on that machine. I prove this by doing this:
Copy code
RUN ./gradlew downloadDependencies
RUN --network=none ./gradlew build
in a Dockerfile In the first project I tried the change above had the desired effect, but in a second project it didn't - the 
RUN --network=none ./gradlew build
fails as so:
Copy code
* What went wrong:
Execution failed for task ':compileGroovy'.
> Could not resolve all files for configuration ':detachedConfiguration3'.
   > Could not resolve org.apache.groovy:groovy-astbuilder:4.0.9.
     Required by:
         project :
         project : > org.apache.groovy:groovy:4.0.9 > org.apache.groovy:groovy-bom:4.0.9
      > Could not resolve org.apache.groovy:groovy-astbuilder:4.0.9.
         > Could not get resource '<https://repo.maven.apache.org/maven2/org/apache/groovy/groovy-astbuilder/4.0.9/groovy-astbuilder-4.0.9.pom>'.
            > Could not GET '<https://repo.maven.apache.org/maven2/org/apache/groovy/groovy-astbuilder/4.0.9/groovy-astbuilder-4.0.9.pom>'.
               > <http://repo.maven.apache.org|repo.maven.apache.org>
   > Could not resolve org.apache.groovy:groovy-dateutil:4.0.9.
     Required by:
         project :
         project : > org.apache.groovy:groovy:4.0.9 > org.apache.groovy:groovy-bom:4.0.9
      > Could not resolve org.apache.groovy:groovy-dateutil:4.0.9.
         > Could not get resource '<https://repo.maven.apache.org/maven2/org/apache/groovy/groovy-dateutil/4.0.9/groovy-dateutil-4.0.9.pom>'.
            > Could not GET '<https://repo.maven.apache.org/maven2/org/apache/groovy/groovy-dateutil/4.0.9/groovy-dateutil-4.0.9.pom>'.
               > <http://repo.maven.apache.org|repo.maven.apache.org>: Try again
I really want to publish 
downloadDependencies
as a plugin, but obviously it needs to be robust to multiple different gradle setups.
Ugh, I was wrong, reverting didn't change it at all. It seems that 
Project.getConfigurations()
does not return 
detachedConfiguration3
. Unclear yet whether it used to in Gradle 7.6, or if 
detachedConfiguration3
is some new thing in Gradle 8.
And I'm wrong, it was broken in 7.6 too, I just wasn't enforcing the 
--network=none
so it was hidden from me.
So where is 
detachedConfiguration3
coming from...
c
there will be many detached configurations created/used by different plugins, for different purposes. Does using the built-in Gradle cache (~/.gradle/caches/…) not work? It has all the POM/module data, source/binary artifacts, etc.
v
You cannot write such a task. You need to actually run each relevant task of such a build.
Detached configuration are not returned from 
configurations
as they are detached. 🙂
A plugin or task can use a detached configuration to use the Gradle resolve / download / cache mechanism to download files without polluting 
configurations
.
There could also be other tasks that do not use detached configurations, but just plainly download things using any other means and that might then even not work offline when run repeatedly
r
There's no way to retrieve the detached configurations of all applied plugins?
v
Only by triggering the codepath that resolves those detached configurations
r
There could also be other tasks that do not use detached configurations, but just plainly download things using any other means and that might then even not work offline when run repeatedly
Yes, I accept there's no way of working around that.
v
Actually, there are plugins like the one you want to write and publish already. They just suffer from the same problems you are hitting. 🙂
r
I guess I've just got lucky until now in my plugins
v
I actually wonder, detached configurations are pretty common, so lucky you. :-D
7 Views
Open in Slack
PreviousNext
Powered by