Handle composite builds

[Arthurm1]

This PR extracts source sets for composite builds - previously, included builds would be ignored.

I've had to get rid of the unique display name code and go with project [sourceset] for all target display names. It just gets far too complicated for little reward when composite builds are added into the mix.

Composite builds have to be handled in the GradleAPIConnector as each included build requires a new ProjectConnection

[jdneo]

I've had to get rid of the unique display name code and go with project [sourceset] for all target display names. It just gets far too complicated for little reward when composite builds are added into the mix.

👍. If it's possible, would you mind separate the display name handling change to another PR?

[Arthurm1]

👍. If it's possible, would you mind separate the display name handling change to another PR?

I've submitted another PR. When that's merged I'll rebase this PR onto it.

[Arthurm1]

rebased

[Arthurm1]

rebased

[jdneo]

I tried this change with a sample in Gradle document site: https://docs.gradle.org/current/samples/sample_composite_builds_basics.html, but it's not working:

Caused by: org.gradle.internal.resolve.ModuleVersionNotFoundException: Could not find org.sample:number-utils:1.0.

It happens when calling sourceSet.getCompileClasspath().getFiles() for the project :app

Maybe it's another issue about how we fetch the classpath, not related with how we handling the include build.

[Arthurm1]

I may have to rethink how this works. I hadn't taken into account dependency substitutions.

Even though it looks like a maven dependency, implementation 'org.sample:number-utils:1.0' in project app actually refers to the project number-utils in the other included build.

[Tanish-Ranjan]

Hi @Arthurm1
I'd be happy to take a look at this PR and potentially contribute. Let me know if there's anything I can do to help move this forward.

[Arthurm1]

@Tanish-Ranjan You're welcome to take over. The main thing is that dependencies into included builds aren't handled as stated here

[Tanish-Ranjan]

Okay, I'll start from there.

[Arthurm1]

@Tanish-Ranjan Hi. Are you working on this? No rush - I just noticed that it's a bit tricky to create the project dependencies

[jdneo]

Hi @Arthurm1, what kind of issue are you facing?

[Arthurm1]

what kind of issue are you facing?

No issue really - I just noticed that we'll have to move the project dependency collection out of SourceSetsModelBuilder and into GradleAPIConnector. Because the included builds have to be retrieved separately on different ProjectConnection.

The archive output jars will also have to be returned by the SourceSetsModelBuilder.

I was going to have a go but wasn't sure if @Tanish-Ranjan was working on it.

[jdneo]

I see. Just to heads up, @Tanish-Ranjan is a participant for the event GSoC (Google Summer of Code). He will work on this open source project during the summer. The composite build is one of the tasks he would like to take.

@Tanish-Ranjan, please let us know if you would like to keep doing this task. If yes, @Arthurm1 is a very experienced and active contributor to this project, and I believe he can definitely give you some guidance for this issue.

To me, I hope we can address this issue ASAP since this will increase the Gradle project import success rate in our VS Code extensions. My plan is to fix it in June.

[Tanish-Ranjan]

Yes @jdneo, I'm happy to take on this task for fixing composite builds. I've been preparing myself by researching composite builds and familiarizing myself with the relevant code. I'd also like to reach out to @Arthurm1 for his guidance. Given his experience with the project, I am confident we would be able to resolve this issue soon.

[jdneo]

No issue really - I just noticed that we'll have to move the project dependency collection out of SourceSetsModelBuilder and into GradleAPIConnector. Because the included builds have to be retrieved separately on different ProjectConnection.

The archive output jars will also have to be returned by the SourceSetsModelBuilder.

May I ask how to handle the problem mentioned in #122 (comment)? Since we still need to get the normal dependencies.

[Arthurm1]

May I ask how to handle the problem mentioned in #122 (comment)? Since we still need to get the normal dependencies.

If the archive dirs are returned in the GradleSourceSet (currently they are not) then in GradleAPIConnector we can check whether they feature in any project's compile classpath. If they do then we can add a project dependency between those 2 projects.
The includedBuilds also need to be returned in GradleSourceSets for each projectdir so GradleAPIConnector can retrieve source sets from all the included builds before the project dependencies can be worked out.
I described this to Tanish on Slack and do have a PR showing it works but I was leaving it to Tanish.

[jdneo]

It's resolved by #154.

Thank you @Arthurm1 for all the effort and help you provided for this issue.