Security plugin should follow standard Gradle multi-project structure
Inside the Security plugin, there are two separate root level Gradle projects: the base project encompassing the entire plugin and a smaller project with its own settings.gradle file inside of the BWC testing directory.
Generally, this is against the recommended practices for building with Gradle. Instead, the Security plugin should be refactored to have only a single settings file with any subprojects branching off of the base path. This is discussed on the gradle website here: https://docs.gradle.org/current/userguide/multi_project_builds.html#sec:creating_multi_project_builds
Having a single settings.gradle file in the root of the multi-project structure would improve maintainability as well as prevent ambiguous organization and configurations.
What solution would you like? Refactoring the bwc test directory underneath src similar to the IntegrationTest directory.
What alternatives have you considered? Leaving as is or keeping the code at the root level are both options.
Do you have any additional context? This was first noticed when I made the changes to enable security to run with BWC tests.
I like the idea of fixing this up from a correctness perspective; however I'm not sure what problems / limits we have with the current layout.
Are there any related issues or scenarios that should work better?
Looking at one of the examples [1] from gradle, each project has their own gradle file so the delta might be a little smaller. I would prefer minimizing the size of the root gradle file to make it more manageable.
- [1] https://docs.gradle.org/current/samples/sample_convention_plugins.html
I don't think there is anything wrong with the current layout. I do think it is against best practices though and is not super intuitive. I still don't know why we have some tests in a completely different section. As for splitting up the files that should be doable but would probably go more along the lines of a general gradle clean up as opposed to simply moving the bwc tests under the standard multi-project structure.
[Triage] This issue is a refactoring change. Going to mark as help wanted for the time being.