Replies: 1 comment
-
Generally one wants an aggregated report so applying only at the root will collect all of the subproject dependencies. This way a shared version catalog can be updated so that versions are updated across all projects. If instead the plugin is applied to a subproject, it will be evaluated only on that subtree. We don't generate a task per configuration/etc so that syntax isn't supported. At the moment we traverse all subprojects, collect all configurations, and evaluate their dependencies. The fine-grained approach you are describing would be ideal to refactor towards, primarily to better match best practices for parallelization and future Gradle compatibility (#263). However this is an old project and none of us have put in the time to do so. PRs welcome if you're interested in that. |
Beta Was this translation helpful? Give feedback.
-
Can you add an example in the readme about how to run this task only for specific projects, build types and variants?
I see this in the readme:
"Alternatively, you can run the task separately in each subproject to generate separate reports for each subproject."
However, it's not clear how to achieve this, and whether we can narrow down the scope further.
For an Android project it would be best if we can do something like:
gradle :app:dependencyUpdatesDevelopmentDebug -Drevision=release
(app - gradle project/module, Development - android build variant/flavor, Debug - build type)
Though I'm not sure if the syntax I'm suggesting makes the most sense.
Beta Was this translation helpful? Give feedback.
All reactions