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

gradle: init-deps.gradle should be dropped on favor of ${gradleBuildTask} --dry-run #381969

Open
britter opened this issue Feb 14, 2025 · 2 comments
Labels
0.kind: bug Something is broken 6.topic: java Including JDK, tooling, other languages, other VMs

Comments

@britter
Copy link
Contributor

britter commented Feb 14, 2025

The init-deps.gradle script - while being a clever way for resolving all dependencies - has some limitations:

  • it downloads way too much for modularized projects if only a subtree is build. It also downloads all build plugins even the ones not required for building the output artifact
  • It's not configuration cache compatible. If a build configured org.gradle.configuration-cache=true in Gradle properties it will result in an error saying:
* What went wrong:
Execution failed for task ':backend:nixDownloadDeps'.
> Could not get unknown property 'configurations' for task ':backend:nixDownloadDeps' of type org.gradle.api.DefaultTask.
  • There's no way of injecting additional command line parameters, such as --no-configuration-cache
  • It's not compatible with isolated projects which will force even more restrictions than configuration cache.

Instead of registering dedicated tasks that force a dependency download for all subprojects and all build scripts, the dependency download should better call the gradleBuildTask with --dry-run. This will evaluate the task graph required for running gradleBuildTask and resolve all required dependencies.

/cc @liff @lorenzleutgeb @chayleaf @FliegendeWurst @Infinidoge @tomodachi94

@FliegendeWurst FliegendeWurst added 0.kind: bug Something is broken 6.topic: java Including JDK, tooling, other languages, other VMs labels Feb 14, 2025
@chayleaf
Copy link
Contributor

That sounds fair, as long as no projects in-tree rely on it for cross platform support. Additionally, it should run the gradleCheckTask since that may have its own dependencies.

@Infinidoge
Copy link
Contributor

So long as it works, absolutely. The less of our own tooling we need the better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0.kind: bug Something is broken 6.topic: java Including JDK, tooling, other languages, other VMs
Projects
None yet
Development

No branches or pull requests

4 participants