fix(gradle): Correctly parse wildcard configuration properties (IDETECT-4853)

[bd-samratmuk]

This change addresses a parsing error in the Gradle init script that occurred when property values contained wildcards.

Issue:
When a property like detect.gradle.included.configurations was set to a value with wildcards (e.g., ompile), the Groovy script failed. The template used single quotes, causing Groovy to interpret the * as a multiplication operator instead of a character in a string, which resulted in a MissingPropertyException.

Fix:
The template has been modified to wrap the filter properties in triple-double quotes ("""..."""). This ensures that Groovy correctly interprets the value as a single string literal, allowing wildcards to be processed as intended by the matching logic.

[Copilot]

Pull Request Overview

This PR fixes a Gradle init script parsing error that occurred when property values contained wildcards. The issue was caused by single quotes in the template causing Groovy to misinterpret wildcard characters as multiplication operators, resulting in MissingPropertyException.

Key changes:

• Modified string literal quoting in the Gradle init script template to use triple-double quotes instead of single quotes

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[dterrybd]

Change seems okay. I'm seeing similar single quote code on lines 11 to 14. Not sure if these need to be addressed as well?

[andrian-sevastyanov]

I tried to understand the full cause of the issue but I'm finding it difficult to do so because there are layers of complexity: how Groovy interprets what is given to it, and how the template engine interprets and renders what is given to it.

The main benefits of triple quotes seem to be that they allow for multi-line strings? I'm guessing the list of filters was getting rendered across multiple lines?
Do you have examples of the rendered script (specifically the sections that are being changed) before and after the change that you could share?

Also, I'm curious if you tested this with longer lists of filters - something like --detect.gradle.included.configurations='*ompileO*,*test*'?

[bd-samratmuk]

@andrian-sevastyanov
What Was Happening
Original Template: The template used single quotes to define the string for the configuration names: '${includedConfigurationNames}'
Substitution: When the template engine replaced '${includedConfigurationNames}' with the value *ompileO*, the resulting line in the generated init-detect.gradle script was: ''*ompileO*''
Groovy did not see this as a single string. It interpreted it as:

1. '': An empty string.
2. *: The multiplication operator.
3. ompileO: A variable or property name.
4. *: The multiplication operator.
5. '': Another empty string.

The build failed because it tried to find a property named ompileO to use in a multiplication operation, and that property does not exist.

By changing the template to use triple-double quotes ("""..."""): """${includedConfigurationNames}"""
The substituted line in the generated script becomes: """*ompileO*"""
Groovy treats anything inside triple-double quotes as a single, literal string. It does not attempt to parse operators or special characters within it. The main benefit of """...""" here is not for multi-line strings, but for creating a "safer" string literal that prevents the Groovy parser from misinterpreting the content. Hope it makes sense.
Also yes the fix is tested with longer lists of filters - something like --detect.gradle.included.configurations='*ompileO*,*test*'

[andrian-sevastyanov]

Thanks, @bd-samratmuk. Any idea where the extra inner ' characters were coming from in the resulting ''*ompileO*''?
And if it was previously appearing there, is it not appearing inside triple quotes? I would expect something like """'*ompileO*'""" to appear.

[bd-samratmuk]

@andrian-sevastyanov I tried investigating that. My guess is that the value passed was wrapped in single quote and then the template also wrapped in single quote hence the quote appeared twice. When using triple quotes that extra quote is not appearing by ensuring the final output is a single, well-formed string literal regardless of what the input value contains.

[andrian-sevastyanov]

@bd-samratmuk, I haven't been able to find anything in FTL documentation that would suggest that inner quotes would be rendered differently in such cases.
Is it possible there are some subtle differences between your testing attempts? For example: using scripts in one case and not the other? Different shells?
I think understanding exactly why the inner quotes are not appearing in the updated version is important as there could be some hidden unsolved issues.

[bd-samratmuk]

@andrian-sevastyanov
The template file wraps the configuration name placeholder in literal single quotes '${...}' , while the data value passed from the Java code already contains its own set of single quotes (this I confirmed, when we are reading from the property we are also reading the single quote). When the template is processed, the engine combines the literal quotes from the template with the quotes from the data value, resulting in the incorrect double single quote output, such as ''compileOnly''.

[andrian-sevastyanov]

@andrian-sevastyanov The template file wraps the configuration name placeholder in literal single quotes '${...}' , while the data value passed from the Java code already contains its own set of single quotes (this I confirmed, when we are reading from the property we are also reading the single quote). When the template is processed, the engine combines the literal quotes from the template with the quotes from the data value, resulting in the incorrect double single quote output, such as ''compileOnly''.

Thanks, @bd-samratmuk. While this change can be merged as-is, I'm not convinced that the originally-reported issue has been addressed. I've shared some info in other channels for you to consider.