Annotation attributes don't pick up constants in imported classes

[ctgnz]

If I use a constant from another class as the value of an annotation attribute (e.g. a public static final String), then I get a compile error: "The value for annotation attribute MyAnnotation.attribute must be a constant expression". The only way I can get the error to go away is to use a String literal, which is not great.

This is in Eclipse Photon. I don't get this error in Eclipse Neon.

The error is only there when JDT compiles the groovy classes - when I run the maven build, there's no compilation problems.

[eric-milles]

Can you share a source example? I do this all the time and it is explicitly tested for. There may be another factor. It is possible you are using a Groovy property. See #336

[ctgnz]

This was in a Concordion spec:

import com.foo.concordion.PlantUmlExtension
import org.concordion.api.extension.Extensions
import org.concordion.api.option.ConcordionOptions
import org.concordion.integration.junit4.ConcordionRunner
import org.junit.runner.RunWith

@RunWith(ConcordionRunner.class)
@Extensions([PlantUmlExtension])
@ConcordionOptions(declareNamespaces = ["ext", PlantUmlExtension.NS])
class MySpecByExample {

}

The problem is the PlantUmlExtension.NS reference. I don't see why it would think this was a property rather than a constant - it is defined as:

class PlantUmlExtension implements ConcordionExtension {
    public static final String NS = "urn:concordion-extensions:2010"
...

If I edit MySpecByExample (even without making an actual change, e.g. type space then delete), and then save the file, the compile error goes away. The compile error only comes back if I do a Project -> Clean.

[eric-milles]

Can you try and reduce it to the minimal code that will recreate the problem. I get no similar error for the following:

package foo
class Bar {
  public static final String BAZ = 'whatever'
}

import foo.Bar
@SuppressWarnings(value=["rawtypes", Bar.BAZ])
class Test {
}

[eric-milles]

Please be sure you are updated with the latest version and let me know what version of Eclipse, etc. you are running.

[ctgnz]

Yes, I get the compiler error on that example, again only when I do a Project clean.

I am running groovy-eclipse 3.0.0.xx-2018062817, with only the Groovy 2.4 compiler installed. My Eclipse is the final release Photon Java developers version, with a couple of Eclipse extras (Web dev tools, DTP).

The project I am working on is using 2.9.2-01 for the compiler in the POM.

[ctgnz]

I also tried creating a new minimal project with just that example, and still get the same issue.

[eric-milles]

Can you take a screenshot that includes the source file open in the editor and the compile error you are seeing? I must be missing something.

[eric-milles]

Can you update and retest after this build finishes? https://build.spring.io/browse/GRECLIPSE-E47M-220

[ctgnz]

I updated with the latest snapshot, and still get the error. Here is a screenshot of the source file and the error message. The only thing I can think of is that for some reason it thinks that PlantUmlExtension.NS is a property rather than a constant, even though that is defined as "public static final". Note that the PlantUmlExtension groovy class is defined in the same project, but in a different source folder - so perhaps it's something to do with the way it is finding and compiling the classes when it is doing a clean?

[ctgnz]

Ah, yes, I think that must be it. We are using Concordion for spec by examples, so we have two separate groovy source folders on our projects, one with general support classes, and the other containing the actual specs (which consist of pairs of a groovy class and a markdown file). I moved the PlantUmlExtension class into another dependent project, and the error went away.

Presumably this is something to do with the way that we add the groovy sources? We use build-helper-maven-plugin to add the test source folders in generate-test-sources.

[eric-milles]

Can you say what the relation between your Spec class and the PlantUnlExtension was? Is it more complex than 2 separate source folders of the same project? Were either indicated as "test" (darker coloration) source folders?

[eric-milles]

I have recently come to understand that there are no errors indicated for unresolved imports. This issue may have been easier to diagnose if those warnings were restored. I just need to think about how to support @Grab at the same time.