ViolationsGenerator skips superclass violations #56
Comments
octylFractal
added a commit
to gradle/gradle
that referenced
this issue
Aug 30, 2022
This is a workaround for melix/japicmp-gradle-plugin#56
|
At first glance I would say that superclasses should be taken into account... I'm confused because I'm pretty sure I saw violations when this happened before 🤔 |
|
It does violate in the normal report, which I don't think I mentioned clearly enough. It's just the rich report that's affected. |
bot-gradle
added a commit
to gradle/gradle
that referenced
this issue
Sep 2, 2022
This is a workaround for melix/japicmp-gradle-plugin#56 I didn't add a test for this one because it's so simple I'd just be writing mocks that match the logic inside. Not really that helpful. Co-authored-by: Octavia Togami <otogami@gradle.com>
bot-gradle
added a commit
to gradle/gradle
that referenced
this issue
Sep 4, 2022
This is a workaround for melix/japicmp-gradle-plugin#56 I didn't add a test for this one because it's so simple I'd just be writing mocks that match the logic inside. Not really that helpful. Co-authored-by: Octavia Togami <otogami@gradle.com>
DPUkyle
pushed a commit
to gradle/gradle
that referenced
this issue
Sep 6, 2022
This is a workaround for melix/japicmp-gradle-plugin#56
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am not 100% sure if this is intentional, but a simple change of superclass is not reported directly as a violation, nor is it passed to any rules to do processing, because
ViolationsGeneratordoesn't callprocessAllChangesforclazz.getSuperclass(). This results in missed coverage if members with empty compatibility changes are skipped, as Gradle does to reduce noise.Reproducer: https://github.com/octylFractal/japicmp-superclass
The text was updated successfully, but these errors were encountered: