When a team has this policy regarding Java-based Spring configuration the current rule types aren't sufficient:
All property values should be provided as beans or public fields in the property configuration class. Whichever mechanism is used, remember that the property placeholder configurer bean must be instantiated to resolve the "${...}" placeholders.
When all property values are provided in the property configuration class, it is therefore implied that no other configuration classes should make any reference to Environment, PropertyResolver (@PropertySource?), or the @Value annotation. Like any other bean in the container, property values should instead be referenced by injecting the property configuration class where needed. There are numerous acceptable ways to make property values accessible from the property configuration class - all of which have only subtle differences that your team may or may not have standardized on.
Possibly the rule "There must be zero to one source file containing match(es) to this expression/pattern." would fit the bill here. We'd then craft an expression that matches on "@Environment", "@PropertySource", or "@Value". Multiple hits within a single file are ok but once matches occur in more than one file all matches found in any file will be flagged.
This one may deserve to live in a different plugin that uses the Java AST. Let's consider sharing this idea with the Sonarqube team at google groups before working on this.
When a team has this policy regarding Java-based Spring configuration the current rule types aren't sufficient:
Possibly the rule "There must be zero to one source file containing match(es) to this expression/pattern." would fit the bill here. We'd then craft an expression that matches on "@Environment", "@PropertySource", or "@Value". Multiple hits within a single file are ok but once matches occur in more than one file all matches found in any file will be flagged.
This one may deserve to live in a different plugin that uses the Java AST. Let's consider sharing this idea with the Sonarqube team at google groups before working on this.