[
https://issues.apache.org/jira/browse/GROOVY-11721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18016623#comment-18016623
]
Eric Milles commented on GROOVY-11721:
--------------------------------------
Could the same transform also add {{BeanInject}}? You may also be able to move
the phase earlier than Semantic Analysis, since it is a global transform.
There may be a conflict between the phase where annotation target is checked
and {{Field}} is applied. If the target checking supported the presence of
{{Field}} -- meaning it would look for ElementType.FIELD not
ElementType.LOCAL_VARIABLE -- would that satisfy what you are looking for?
If there is a transform applied and the IDE does not pick up on it, that's an
IDE issue.
Is the extra boilerplate of a class for testing too much? The script route
seems like it will run into more issues than just fields.
> @groovy.transform.Field to annotate a script class
> --------------------------------------------------
>
> Key: GROOVY-11721
> URL: https://issues.apache.org/jira/browse/GROOVY-11721
> Project: Groovy
> Issue Type: New Feature
> Affects Versions: 5.0.0-beta-2
> Reporter: Bartosz Popiela
> Priority: Major
> Attachments: image-2025-08-27-14-08-33-523.png
>
>
> We use undeclared Groovy Scripts together with JUnit for writing unit tests
> because it supports sentences as method names and doesn’t impose restrictions
> on the file name (we need the test script name to match the name of the YAML
> file being tested). This solution works very well; the only downside is that
> in order to use annotations on a field, such as [email protected]_, we
> also need to use [email protected]_, since those annotations typically
> don’t have target = LOCAL_VARIABLE. It would be convenient if _@Field_ could
> be placed on the script class (with _@Inherited_ to support a base script)
> and be automatically applied to all local variables in the script
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
