[ 
https://issues.apache.org/jira/browse/GROOVY-11721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18016780#comment-18016780
 ] 

Eric Milles commented on GROOVY-11721:
--------------------------------------

> 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

This applies to Groovy classes as well.  You don't need to use a script and 
have this issue with fields to write JUnit tests.

Did you try the annotation collector option?  I'm curious to know if it would 
still produce a target warning.

Did you try changing the phase of your global transform to Conversion?

Are you saying that IntelliJ does not detect the application of the Field 
transform because it is not directly represented in the source?  That seems 
like a limitation of IntelliJ/PSI.

> it would become feasible for IDEs to infer the actual target (field vs local 
> variable)

It seems like you are trying to design something that an IDE _could_ support.  
I would expect this kind of issue gets filed with IntelliJ and they have a look 
as to what they can do about it and what language support they might require.  
Eclipse IDE detects transforms applied in the conversion phase and semantic 
analysis phases.

> @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, 
> image-2025-08-28-02-47-30-911.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)

Reply via email to