Document that spring-boot-configuration-processor cannot detect default value defined externally

[wangliang181230]

<artifactId>spring-boot-configuration-processor</artifactId> cannot generate the default value to the spring-configuration-metadata.json when the field default value is a constant and the constant not in current class.

[wilkinsona]

Depending on exactly where the constant is defined, I have a feeling that it may not be possible to access it from the annotation processor. Can you please expand a bit on what you mean by "and the constant not in current class". Is the constant defined in another class in the project that's being compiled, or is it an external dependency?

[wangliang181230]

Depending on exactly where the constant is defined, I have a feeling that it may not be possible to access it from the annotation processor. Can you please expand a bit on what you mean by "and the constant not in current class". Is the constant defined in another class in the project that's being compiled, or is it an external dependency?

another class or another jar

[wilkinsona]

Thanks. That's a bit ambiguous. Do you mean another class in another jar, or you have two different cases one where the class is in the same project and one where it is in another jar?

[wangliang181230]

Thanks. That's a bit ambiguous. Do you mean another class in another jar, or you have two different cases one where the class is in the same project and one where it is in another jar?

yes, two cases

[wangliang181230]

Thanks. That's a bit ambiguous. Do you mean another class in another jar, or you have two different cases one where the class is in the same project and one where it is in another jar?

One case is another class in same project.
One case is another class in another jar.

[snicoll]

One case is another class in same project.

That's a current limitation of the annotation processor I am afraid. We need to browse through source code elements to figure out what the default value should be and we support a limited set of use cases at the moment.

One case is another class in another jar.

This won't be supported. We don't have access to the source code of classes that are not being compiled so we can't infer what the elements we have in the current class refers to.

[snicoll]

We've discussed this one at the team meeting and decided to document the limitation (which is what I've just done). If you need to configure your constants externally, I am afraid we won't be able to detect those.