-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Please also add @DaggerGenerated to generated nested classes #4540
Comments
Just a small note:
This is not what they said. Your second bullet is their only limitation. Class files contain a very explicit and easy-to-parse pointer to the enclosing class (if any), but getting any details about that class other than the relationship does require that it also be parsed which they are choosing not to do. |
Hmm, I didn't express myself very well then :-) While didn't know how exactly, even I assumed that the inner-class was somehow identifying its outer class. Even static inner classes. So yes, my first bullet point doesn't really hold and was more my hallucination. My understanding is that an enhancement in JaCoCo would be quite a big change. This is why I made the request here - hoping for a solution which is less intrusive. |
Sorry, I'm not too familiar with JaCoCo. Is JaCoCo like hard-coded to look for
It might be worth pushing a bit in jacoco/jacoco#1815. In particular, I don't think they actually said how big the change would be. I took the comment more as just a statement of how things currently work, so perhaps they would be okay with accepting the feature request if you pushed.
This isn't difficult, per-se, but it's a bit annoying to track all of these down and keep it up to date. If you want to give it a try we can accept a PR. |
JaCoCo will look for an annotation with " Also this answer to a StackOverflow question about annotation-based coverage filtering with JaCoCo. |
Dagger- generated code has the
@Generated
and the@DaggerGenerated
annotations on top level classes of all generated Java source files.The firster nicely allows source code scanning (e.g. static analysis) tools to recognize the code as generated, and to skip those classes. Also, implying that inner (or nested) classes of such code must also be generated code, to skip them too.
Sonar Scanner for example does this just fine.
JaCoCo, which scans class files, is different and will, for example, include generated classes like
*_Factory.InstanceHolder
or*ComponentImpl
in its scans, even when excluding their respective directly annotated*_Factory
/Dagger*Component
outer classes.I made feature request jacoco/jacoco#1815 for an improvement on this, and got an explanation basically pointing out:
@DaggerGenerated
would mean no longer being able to look at class files one-by-one.While the code for
@Module
s and@Component
s mostly resides in packages separated from other code - and I can thus add scanning exclusions for them by their package - the factory code for@Inject
annotated classes is generated next to them.I can still apply exclusion patterns but this requires knowledge of Dagger internals, which is uglier IMHO (but here you are for
jacoco-maven-plugin
:<exclude>**/*Factory$InstanceHolder.class</exclude>
).So it would be much nicer if all classes generated by Dagger got the
@DaggerGenerated
annotation ... generated.The text was updated successfully, but these errors were encountered: