Dependency considers annotations

[kosani]

Dependencies now consider annotations, nested annotations and annotation parameters.

Supported:

• Dependencies on class, field, method and constructor annotations.
• Dependencies on annotation parameters.
• Dependencies on nested annotations (and parameters).

Not supported

• Method parameter annotations.
• Meta annotations.

Resolves #136

[codecholeric]

Just to let you know, I'm on it! Sorry that it took me so long!!
It's surprisingly complex, I've already made some adjustments, one bigger one because I think to be consistent we have to make the JavaAnnotation.owner the closest element where it is declared. Because ThrowsDeclarations for example have the method or constructor where they are declared on as their "owner", so I think to be consistent JavaAnnotation must have the class, but also maybe the field or even the annotation where it is declared as parameter as "owner".
I know that "owner" concept is a little fuzzy, because it's pretty generic 😉
Anyway, thus I'm still on the review, but I hope I'll get through with it within the next days. I'll probably still release a new minor upgrade of ArchUnit, because I don't want to block Java 14 support with this review.

[codecholeric]

What I also think, is that meta-annotations are actually irrelevant for this issue. Because a meta-annotation is a transitive dependency which we don't consider in any other place, so we should not do it here either.
E.g. if a class B extends a class A and a class declares a field of type B, we don't report a dependency on type A. For me meta-annotations are exactly the same. You can still test this yourself, or we'll add a library function like requested in #253. But it does not have to be covered by the low level API of JavaClass.

[ghost]

DeepCode's analysis on #bf0ac8 found:

• ❌ 0 critical issues. ⚠️ 0 warnings and 6 minor issues. ✔️ 3 issues were fixed.

💬 This comment has been generated by the DeepCode bot, installed by the owner of the repository. The DeepCode bot protects your repository by detecting and commenting on security vulnerabilities or other critical issues.

---

☺️ If you want to provide feedback on our bot, here is how to contact us.

[codecholeric]

@kosani I've finally gotten around to reviewing your PR!! I'm really sorry that it took so long, not gonna make excuses ☹️
Can you look over my changes and see if it makes sense?
Thank you so much for your hard work!! Except from the refactoring from the concept change of "owner", it worked really well, good job 😄
Can't wait to finally merge this into master and have another important piece in place!!

[kosani]

@codecholeric I've looked at the changes.. I had to glance through a few of them since there has been a lot of changes since April. From what I see, some new domain concepts were introduced that remove a lot of clutter that providing annotation dependencies introduced.

Thank you for the review! I will definitely come back and give a more thorugh look, but from what I see, all of this seems very reasonable!

[codecholeric]

I just noticed that enum constants as annotation parameters are not recognized yet...
I'll try to fix that over xmas!!

[codecholeric]

I'm finally done, thank you so much for your hard work @kosani !! And sorry that it took me so long, this issue I definitely underestimated badly. I overlooked the other way around when I added the enum support, thus if you did someEnumType.getDependenciesToSelf() the class bearing an annotation with an enum parameter of that type was not detected. I noticed that there was pretty much the same structure (array traversal and instanceof checks missing the enum case) in ClassGraphCreator, so I unified the traversal logic and added a new annotation API implementing some visitor pattern (if you want to check it out).