This message was deleted.
# community-support
s
This message was deleted.
v
figured I'd change threads
👌
wdym
By using
it.tasks
you reach into the model of the subproject which is bad. It works in this case as the task is always there, but latest with project isolation this should fail. With the string-y version I suggested instead you should not have that problem.
c
> but latest with project isolation this should fail what?
with the stringy version though more chance of typo... 😢 I hate strings, they are weakly typed imo
j
I have a similar question, the problem is I want to get all tasks by type, doing it with a regex can be hard
Copy code
// TODO: Remove `allprojects` as it is incompatible with project isolation
val testResults: List<TaskCollection<Test>> =
    project.allprojects.map { it.tasks.withType<Test>() }
allTestsReportTask.configure { task ->
    task.destinationDirectory.set(allTestsDir)
    task.testResults.from(testResults)
}
I have that
TODO
as I was thinking in using some custom configuration to aggregate everything, but it would be a bit annoying
v
>> but latest with project isolation this should fail > what? What what? With enabled project isolation (currently in experimental state) I don't think that doing such bad-practice reaching into other projects models is allowed. > with the stringy version though more chance of typo... 😢 I hate strings, they are weakly typed imo Yes, I'm fully with you and also always prefer non-string-y variants where possible. So, the proper way would be to declare an outgoing configuration on the subprojects that has an artifact that is built by
dependencies
(doesn't really have to build it, it just needs to be stated that it is coming from there) and then depend on that configuration from the root project. But imho it is too much ceremony for this use-case and here the string-y version should be appropriate. 🙂 > I have that
TODO
as I was thinking in using some custom configuration to aggregate everything, but it would be a bit annoying Well, as I just also described this, that's indeed the way to go for inter-project sharing / depending if not wanting to reach into other projects models and not wanting to use string task dependencies. 🙂