feat(ast): extend support for annotation named parameters

[zhumin8]

[updated]
This change is to extend annotation arguments support.
Before: Only one argument that consist of a single String can be added to annotation description.
After: For single unnamed parameter/description, add support for ValueExpr and VariableExpr in addition to String. Also allow adding multiple named parameters of type VariableExpr. So that annotations like below can be generated:

@ConditionalOnClass(VisionServiceClient.class)
@ConditionalOnProperty(value = "spring.cloud.gcp.vision.enabled", matchIfMissing = true)

this improvement is an addition and does not affect existing usage of setDescription(String description).
Added tests in JavaWriterVisitorTest.java also shows the new feature usages.

[blakeli0]

We already have a way to achieve the same thing, see the code here and the golden test file here. I think it's better not to have different ways to achieve the same thing, it would create more maintenance burden in the future. If you want, you could extract the common logic to a util method/class, something like createClazzValueExpr or createClazzVariableExpr, which only takes type as an argument.

[zhumin8]

Ah, thanks for the tip. I couldn't wrap my head around needing a Value instead of Variable.

[blakeli0]

I like this improvement in general, but we should be careful exposing a setter that can set descriptions to any Expr, you can technically pass a NewObjectExpr or a ReturnExpr and everything will work until we try to compile the generated code, which could be too late to find an issue.
Correct me if I'm wrong, I think we only allow ValueExpr, AssignmentExpr, or VariableExpr(for clazz if you remove CLazzValue). So we could either add some type checks in the build() method, or only expose methods to add descriptions for the above types, like addDescription(ValueExpr expr), addDescription(AssignmentExpr expr) and addDescription(VariableExpr expr).
Basically anything that could restrict people from passing any types of Expr would be great.

[zhumin8]

Good point, let me refactor this part and expose methods for each expr type.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

97.5% Coverage
0.0% Duplication

[zhumin8]

Adding a small enhancement to this PR since it's related.
In addition to previous changes, I added an optional field to VariableExpr allowing Annotations.
Prior to this, only annotations on ClassDefinition and MethodDefinition are supported. With this addition, I will be able to generate code like:

  @NestedConfigurationProperty
  private final Credentials credentials = new Credentials();

  // or 
  @Autowired
  private LanguageServiceClient autoClient;

Field annotations are pretty common in Spring syntax, this enhancement is needed to generate Spring autoconfig code as I planned.
Note: Added a todo note in VariableExpr only as a nice to have feature for future, it's not blocking any use cases for now. But it seems reasonable to have target info in AnnotationNode and apply checks on it when adding annotation nodes.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

98.0% Coverage
0.0% Duplication