-
Notifications
You must be signed in to change notification settings - Fork 275
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added a new unit test to check the use of variables in the plugins section in a Gradle file #3900
base: main
Are you sure you want to change the base?
Conversation
Added a new unit test using variables in plugins section, because there was an error caused by that.
…h_variables Update FindPluginsTest.java
Thanks for adding this test @lnnery ! Helpful indeed to track support for this use case too. In parallel there's also some efforts underway on the use of You might be interested to follow those as well, and the plans there to create a ScanningRecipe to handle gradle.properties files, as well as the associated Slack thread. |
Added missing import.
Sharing the failure here for easier visibility
|
You might want to keep an eye out on this PR as well, which adds similar support to UpgradePluginVersion: |
The above PR #3933 has now been merged, and the same approach can likely be replicated here to allow finding plugins which use properties in their version number. |
Still the same failure here for |
Hi @ajohnsonz, adding you here as requested by @timtebeek :) |
Ah yes, thanks @lnnery ! Figured @ajohnsonz might have some insights to share as to what's needed to make |
We might need to be mindful that if FindPlugins is currently used as a precondition, then we can not simply convert it into a scanning recipe, as scanning recipes are not supported as preconditions. |
Hi @lnnery @timtebeek - you can certainly take a look at It really depends if you care about finding the plugin and also knowing the version, or if you just care about finding the groupId and artifactId - if the latter, a simple |
Thanks for chiming in! Looking at how FindPlugins is used in AddPluginVisitor it might make most sense indeed to add that |
I've pushed up a minimal change to prevent that cast exception; figured easier to iterate if there's something to critique. This now returns the variable name, which I don't think we have to resolve to be able to satisfy FindPlugins responsibility. It seems we only use this from |
What's changed?
Added a new unit test to check the use of variables in the plugins section in a Gradle file. There was an error when using variables in this section, and that was what led to the creation of the new test.
Have you considered any alternatives or workarounds?
Yes, if the variables are removed from the plugins section everything works, however, this is not a good approach as it requires changing the Gradle file.
Checklist