This message was deleted.
# community-support
s
This message was deleted.
s
a
you can add a dependency on a task from another subproject by using the full path https://docs.gradle.org/8.2/userguide/more_about_tasks.html#ex-adding-dependency-on-task-from-another-project If you want to get a list of all projects, then you can use
allProjects
.
Copy code
val report by tasks.registering {
  dependsOn(
      // note: this is usually bad practice - see below
      allprojects.map { otherProject -> 
        otherProject.task("collect")
      }
  )
}
However... even though it's easy to write and Gradle will let you do it, it's considered bad practice for a number of reasons. The 'better', but significantly more complicated, way is to use Configurations to share files.
🤔 1
z
Producer subprojects store their output in a configuration, and consumer project (in this case, the root project, though it doesn't need to be) access those files via the
dependencies { }
block
1
This is how one Android subproject depends on output produced by another android subproject
😲 1
s
The
allprojects
piece didn't seem to work (I know it's the wrong way):
Copy code
private fun registerOnRootProject(rootProject: Project) {
    val rootProjectFeatureUsageReportTask: TaskProvider<FeatureUsageReportTask> =
      rootProject.tasks.register(
        FeatureUsageReportTask.TASK_NAME,
        FeatureUsageReportTask::class.java
      ) {
        it.setParams(
          project = rootProject
        )
      }

    rootProject.allprojects.forEach { otherProject ->
      val collectTask = otherProject.tasks.findByName(FeatureUsageCollectDependenciesTask.TASK_NAME)
      rootProjectFeatureUsageReportTask.dependsOn(collectTask)
    }
  }
z
If you're going to do it the wrong way, the subprojects should add their dependency to the root project task when the subprojects are configured
What you really should never be doing is looping over subprojects from the root project. Convention plugins allow you to avoid this
What you really should never be doing is looping over subprojects from the root project. Convention plugins allow you to avoid this
actually, I don’t know if it’s worse to access the root project from a subproject, or if it’s worse to access the subproject from the root project
you want
subprojects { }
- not
allprojects { }
-
allprojects
will loop over the root project, which you do not need, bc it is doing the aggregation
if you are looping over subprojects from the root project, you will have to add some
plugins.withId(..) { }
to wait until the relevant plugins are applied to wait until your subproject producer tasks are registered
can also use an
afterEvaluate { }
but that invites other issues around timing depending on what exactly you’re doing
👍 1
s
If you're going to do it the wrong way, the subprojects should add their dependency to the root project task when the subprojects are configured
I've tried this and it didn't work... But so many caches and things, maybe just have to try again.
z
if you need 2 gradle invocations, it just means you aren’t wiring up your dependencies correctly. I don’t know you’re use case, but it likely means that you have some issue with how you are wiring up your `Provider<T>`s
specifically with regard to task input/output. for example, don’t look something up in the file system if it’s output from another task - use
task.outputs
and filter on it as appropriate
v
maybe just have to try again.
Please do not. You were already told the proper and safe way to share things cross-project. You can also have a look at the Jacoco Report Aggregation plugin or the rest report Aggregation plugin. Both use the proper way and by using a lenient artifact view support that not all projects are producers, so exactly what you want.
👍 2
😂 1