Support for ignoring classes that cannot be fixed
Closed this issue · 5 comments
See https://github.com/gaul/modernizer-maven-plugin/tree/master/modernizer-maven-annotations for example.
Currently if a specific class has a restricted import that cannot be addressed such as some usage of spring jdbc extended logic that forces imports on say commons logging due to required overrides, we must turn this completely off. That loses the point entirely due to one class. It would be better to have ability to add an annotation to a class similar to done with modernizer maven annotations project does for similar reasons. I have no experience doing that, but given the example above, I'd be more than happy to help contribute to make this happen.
For my usage, I am one of the leads on a very large supporting devops team and we try to enforce best practice across 2k+ repos. We use this and have ability to turn off and on globally per project and try to discourage class usage that conflicts. Currently we are also starting to to block all junit 4 or before usage but some things like junit4 rules are harder to deal with when entirely customized and tools like open rewrite are unable to magically rewrite them. Having such an annotation to scan and skip looking on listed classes is a modern way to do this and would greatly benefit in our goal if blocking all junit 4 as possible without entirely turning this off.
That is quite an interesting use case I haven't thought about until now. You are right, it is currently not easily possible to fine tune allowed imports on a per-class basis without either repeating the whole restriction configuration per class or losing the whole restriction configuration for that specific class.
I have some objections to using annotations to fix this problem though.
- Though it turned out to lead to inaccurate results, I still like the idea of not having to completely parse each source file. That is why currently, the accurate parsing is still opt-in.
- This plugin is intended to provide light-weight configuration from the outside of the actual code. I don't feel comfortable adding a source level dependency just to have this feature. That is also in the interest of the users as I believe not everyone is keen on sprinkling their code base with yet another proprietary annotation type.
What I could imagine is an extra configuration section in the XML, stating that certain imports are allowed in certain classes. Roughly like this:
<RestrictImports>
<reason>Use SLF4j for logging</reason>
<bannedImport>java.util.logging.**</bannedImport>
<allowedPerClass>
<in>com.foo.my.enterprise.Xyz</in>
<allow>org.apache.commons.*</allow>
</allowedPerClass>
</RestrictImports>If we really really really were to solve this with annotations, then probably by adding an annotation-processor as well. The processor could generate some kind of ignore file for our rule to read. That would at least save us from relying on full compilation unit parsing. Still this sounds a bit too complex for me
I've linked a pull request that will solve this issue via an XML configuration as outlined in my previous comment. Feel free to leave some feedback. I'm not especially happy with the naming yet so that's likely subject to some change.
Added feedback on PR.
If you want to give it a try: this feature can already be tried out using the recently released 2.4.0-rc1 version of the rule.
The Readme on master is already up to date with information on how to use it
Released in 2.4.0