Add GeneralCodingRule to discourage use of field injection #289
Conversation
|
👉 View analysis in DeepCode’s Dashboard |
archunit/src/main/java/com/tngtech/archunit/library/GeneralCodingRules.java
Outdated
Show resolved
Hide resolved
archunit/src/main/java/com/tngtech/archunit/library/GeneralCodingRules.java
Show resolved
Hide resolved
archunit/src/main/java/com/tngtech/archunit/library/GeneralCodingRules.java
Outdated
Show resolved
Hide resolved
archunit/src/main/java/com/tngtech/archunit/library/GeneralCodingRules.java
Outdated
Show resolved
Hide resolved
archunit/src/main/java/com/tngtech/archunit/library/GeneralCodingRules.java
Outdated
Show resolved
Hide resolved
archunit/src/main/java/com/tngtech/archunit/library/GeneralCodingRules.java
Outdated
Show resolved
Hide resolved
Resolves TNG#288 Signed-off-by: Roland Weisleder <[email protected]>
This way we can easier reuse centrally managed dependencies in other contexts like the `maven-integration-test`. Signed-off-by: Peter Gafert <[email protected]>
We should reuse the centrally managed dependencies for both the example and the `maven-integration-test`. To achieve this I have extended the simple pom templating mechanism to support replacements like `#{dependency.junit4:test}` by the respective Maven dependency `<dependency>...</dependency>`.
Signed-off-by: Peter Gafert <[email protected]>
because we want to have one example for every library rule, but then the unit test is obsolete. Also this way it is consistent to how the other rules are tested and we keep the core `archunit` module free of extra dependencies for frameworks. Note that the Shadow plugin actually rewrites all string occurrences of a package to repackage within the bytecode. Thus I had to narrow the relocation of `com.google` for Guava to `com.google.common` and `com.google.thirdparty`, because otherwise the string constant `com.google.inject` is actually rewritten in the bytecode to `com.tngtech.archunit.thirdparty.com.google.inject` and the rule does not work anymore. Signed-off-by: Peter Gafert <[email protected]>
Signed-off-by: Peter Gafert <[email protected]>
There was a problem hiding this comment.
I finally got around to looking into it again, thanks a lot!! 😃
I've squashed your commits, hope that is okay. Then I added a review commit migrating the test to an example + integration test, because that is how all the other general rules are tested (that way there is also an example in the example project for people to check out).
When I did this and added a Google Guice test, I noticed something really unexpected though 🤦♂️ . The Gradle Shadow plugin rewrites all string constants in the bytecode. So even though you wrote stringly "com.google.inject.Inject" without any reference to a class, in the bytecode this constant became com.tngtech.archunit.thirdparty.com.google.inject.Inject rendering the condition useless. I've only noticed because I migrated it to an example rule and thus the Maven Integration test failed (since that one actually uses the real packaged archives).
Anyway, now I've also improved the Maven Integration test a little to build the POM from the managed dependencies, so that's a nice side effect 😃
That's why I love a sufficient number of black-box tests against the final release though...
Disallow fields to be annotated with common injection annotations like `@Autowired` or `@Inject` to encourage constructor injection instead.
Resolves #288