[build] Settings.gradle's logic to handle different buildFile name could result in phantom subproject

[guesshe]

Expected Behavior
Regardless of the buildFile names, no phantom subprojects should be created.
 

If a subproject has a default buildFile name like build.grade, the build setup should NOT create a phantom subproject.
 
Current Behavior
If a new subproject is added in with structure like this spring-security-foo/spring-security-foo-bar, using a default buildFile name build.gradle under spring-security-foo-bar will result in the creation of a phantom subproject spring-security-foo.

No phantom subproject should be created due to the name change of the buildFile.

Context
Settings.gradle should be updated to give a consistent behavior for different buildFile names.

[sjohnr]

@guesshe thanks for reaching out. Why do you need to create a subproject under spring-security? What exactly do you mean by “phantom subproject”? Can you please explain what issues you are having with the behavior of the settings file?

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[spring-projects-issues]

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

[guesshe]

@guesshe thanks for reaching out. Why do you need to create a subproject under spring-security? What exactly do you mean by “phantom subproject”? Can you please explain what issues you are having with the behavior of the settings file?

Sorry, I missed the notification. The issue is described here in gradle's documentation. https://docs.gradle.org/8.12/userguide/multi_project_builds.html. It will happen when creating a new sub-project if this settings.gradle file is used for both default buildFile name and custom buildFile name.

[guesshe]

A quick test showed that a new subproject with default buildFile name, build.gradle will result in a phantom subproject created from the parent folder. However, if using custom buildFile name like foo-bar.gradle, no phantom subproject is created. Following code snippet should fix the issue.

buildFiles.each { File buildFile ->

    boolean isDefaultName = 'build.gradle' == buildFile.name
    if (isDefaultName) {
        String buildFilePath = buildFile.parentFile.absolutePath
        String projectName = buildFilePath.tokenize(File.separator)[-1]
        configureProject(':' + projectName, projectName, buildFile)
    } else {
        String projectName = buildFile.name.replace('.gradle', '')
        configureProject(':' + projectName, projectName, buildFile)
    }
}

def configureProject(String projectPath, String projectName, File buildFile) {
    include(projectPath)

    def project = findProject(projectPath)
    project.name = projectName
    project.projectDir = buildFile.parentFile
    project.buildFileName = buildFile.name
}

[sjohnr]

Hi @guesshe, thanks for replying. I think I see now what you're saying. For some reason, I wasn't understanding the original post description fully.

Would you like to submit a PR to fix this? If so, please keep in mind that the project also supports Kotlin modules (though we don't have any currently), so I think we should keep support for build files ending in .gradle.kts as well.

[guesshe]

Thanks for your reply! Sure. I can issue a PR to fix this. Probably sometime later this week or next.

…

On Wed, Jan 8, 2025, 16:59 Steve Riesenberg ***@***.***> wrote: Hi @guesshe <https://github.com/guesshe>, thanks for replying. I think I see now what you're saying. For some reason, I wasn't understanding the original post description fully. Would you like to submit a PR to fix this? If so, please keep in mind that the project also supports Kotlin modules (though we don't have any currently), so I think we should keep support for builds ending in .gradle.kts as well. — Reply to this email directly, view it on GitHub <#16322 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKCJEHW7JF5CQFMU76GMWJT2JWNSLAVCNFSM6AAAAABT7PIYBWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZYG42DKOJVG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[guesshe]

Apologies, I wasn't sure how to reopen an issue so I creared a new one. You can close the new one as a duplicate. I will use this one to issue the PR.

…

On Wed, Jan 8, 2025, 17:10 guesshe ***@***.***> wrote: Thanks for your reply! Sure. I can issue a PR to fix this. Probably sometime later this week or next. On Wed, Jan 8, 2025, 16:59 Steve Riesenberg ***@***.***> wrote: > Hi @guesshe <https://github.com/guesshe>, thanks for replying. I think I > see now what you're saying. For some reason, I wasn't understanding the > original post description fully. > > Would you like to submit a PR to fix this? If so, please keep in mind that > the project also supports Kotlin modules (though we don't have any > currently), so I think we should keep support for builds ending in > .gradle.kts as well. > > — > Reply to this email directly, view it on GitHub > < #16322 (comment)>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AKCJEHW7JF5CQFMU76GMWJT2JWNSLAVCNFSM6AAAAABT7PIYBWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZYG42DKOJVG4> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#16322 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKCJEHUDCYWEWV5AHQ5TJOD2JWO5JAVCNFSM6AAAAABT7PIYBWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZYG43DSMRRGQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>