Iterate over an included build's subprojects

For my project, I have an included build with four subprojects. Upon the program’s build, I need to run the jar task on each of these subprojects, but I can’t figure out how I can retrieve them in anyway to do so. Whilst looking around, I found gradle.includedBuilds, which I thought would be helpful but I don’t think I can get what I need from what it returns

Is it possible to do what I need?

Can you describe the actual use-case?
The need to depend on jar tasks in included builds is very uncommon and there is probably a better and cleaner solution.

Thank you for responding! This is for the previous project you replied to a question for. Upon creating a distribution of the program, I have it loop the subprojects and run the jar task on each to get form a build version of each plugin (should be replaced with the shadowJar task). It does so with this code

Perhaps there’s a way I can gather the jar results from the included builds results and pass them to the main one? It’s difficult to separate the subprojects of this included build as some depend on others

You should definitely not try to depend on tasks of included builds or use their output directly.
You should not even do that between different projects of the same build.
You can read more about that here: Gradle User Manual: Version 7.0

When using composite builds (includeBuild) you actually just declare a dependency on the component that is built by the project in that build. So if project X in included build A produces the artifact with group “foo” and artifact name “bar”, then you just add a dependency on foo:bar and this will be replaced by the respective sub-build from the included build automatically.

Which actually is what I told you already in that other thread, isn’t it?

The other thread was for the dependency when running, this thread is for that dependency when building. The reason why I do need the output of jar, is so I can, during the distributions content, copy that output into a different folder, in this case the plugins folder, to then be loaded at runtime by my plugin framework

In the end, this was solved by converting includeBuild 'libs/sniffle' (a build of subprojects) to this;

[/*'discordrpc',*/ 'pluginmanager', 'settingsgui', 'tipoftheday'].each {
    include it
    project(":$it").projectDir = new File(settingsDir, "libs/sniffle/$it")

Actually this does not make it any better.
You can also iterate over the tasks of projects of included builds and abuse them like you do.
But you should not do that.
I linked you to the documentation where it explicitly says that this is bad, might not work properly and fights several optimizations like ability to build in parallel in the future. That docu also shows you how to properly depend on output of other projects or other builds.

If you need those artifacts separately to package them in a separate folder, then declare a separate resolvable configuration to which you add those as dependencies and then use that configuration to get hold of the result for packaging.

1 Like