在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
开源软件名称(OpenSource Name):melix/japicmp-gradle-plugin开源软件地址(OpenSource Url):https://github.com/melix/japicmp-gradle-plugin开源编程语言(OpenSource Language):Java 75.9%开源软件介绍(OpenSource Introduction):JApicmp Gradle PluginInstallationThis plugin requires Gradle 6+. Use the following snippet inside a Gradle build file: plugins {
id 'me.champeau.gradle.japicmp' version '0.4.0'
} or (not recommended): build.gradle
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'me.champeau.gradle:japicmp-gradle-plugin:0.4.0'
}
}
apply plugin: 'me.champeau.gradle.japicmp' ConfigurationThe plugin provides a new task type:
If you don’t set oldArchives and newArchives, the plugin will infer them from the oldClasspath and newClasspath properties:
UsageAdd the following to your build file: tasks.register("japicmp", me.champeau.gradle.japicmp.JapicmpTask) {
oldClasspath.from(files('path/to/reference.jar'))
newClasspath.from(tasks.named('jar'))
onlyModified = true
failOnModification = true
txtOutputFile = layout.buildDirectory.file("reports/japi.txt")
} Custom filteringThe plugin supports adding filters for bytecode members before they are considered for API comparison: tasks.register("japicmp", me.champeau.gradle.japicmp.JapicmpTask) {
...
addIncludeFilter(MyCustomFilter)
addExcludeFilter(MyOtherFilter)
} where For example, adding the following filter as an exclude filter will hide fields that are annotated with class MyOtherFilter implements FieldFilter {
@Override
boolean matches(CtField field) {
return field.hasAnnotation("Custom") || field.name.contains("Custom")
}
} Custom reports and failure conditionsThe plugin supports a DSL to generate custom reports based on the API comparison result. This has several advantages:
ConfigurationThe report can be configured using the tasks.register("japicmp", me.champeau.gradle.japicmp.JapicmpTask) {
...
richReport {
...
}
} Options for the rich report are:
If no rules are explicitly defined, the default rules are applied. If any rule is added, the default rules won’t be applied unless Custom rulesRules are used to add violations to the report. The "violation" term must be taken in a simple sense, as it represents data to be shown in the report, whether it’s a critical violation or just information. A violation consists of a triplet (member, severity, explanation), that will be seen in the report. For example, if a binary incompatibility is found, you can create a violation using:
which will automatically assign it to the Rules can be applied to 3 different levels:
Rules are executed in the following order:
For example, imagine that we want to check that all new methods are annotated with class IncubatingMissingRule implements ViolationRule {
@Override
Violation maybeViolation(final JApiCompatibility member) {
if (member instanceof JApiMethod) {
if (!member.annotations.find { it.fullyQualifiedName == 'org.gradle.api.Incubating' }) {
if (!member.jApiClass.annotations.find {
it.fullyQualifiedName == 'org.gradle.api.Incubating'
}) {
Violation.error(member, "New method is not annotated with @Incubating")
}
}
}
}
} and then you need to configure the report to use that rule: richReport {
addRule(JApiChangeStatus.NEW, IncubatingMissingRule)
} Rules can take arguments, but those are limited to class AcceptedRegressionRule implements ViolationRule {
private final Map<String, String> acceptedViolations
public AcceptedRegressionRule(Map<String, String> params) {
acceptedViolations = params
}
@Override
Violation maybeViolation(final JApiCompatibility member) {
if (!member.binaryCompatible) {
def acceptation = acceptedViolations[Violation.describe(member)]
if (acceptation) {
Violation.accept(member, acceptation)
} else {
Violation.notBinaryCompatible(member)
}
}
}
} and here’s how the rule is applied: richReport {
addRule(AcceptedRegressionRule, acceptedViolations)
} Setup and post-process rulesSince release 0.2.2, the plugin also supports setup and post-process rules. Setup rules allow setting up some global
context that can be accessed by rules extending Setup rules need to implement class MySetupRule implements SetupRule {
@Override
void execute(final ViolationCheckContext violationCheckContext) {
// this is going to be executed before any other rule is executed
violationCheckContext.userData.executed = false
}
} and declared using richReport {
addSetupRule(MySetupRule)
} Then the context can be accessed in rules implementing class ContextAwareRule extends AbstractContextAwareViolationRule {
@Override
Violation maybeViolation(final JApiCompatibility member) {
// this rule is accessing the global context and can mutate user data
context.userData.executed = true
return null
}
} And then a post-process rule has access to the user data, and can also mutate the actual list of violations per class, before the report is generated: class MyTearDownRule implements PostProcessViolationsRule {
@Override
void execute(final ViolationCheckContextWithViolations violationCheckContextWithViolations) {
// this rule is executed once all checks have been performed, just before the generation
// of the report
// it gives the opportunity to add additional violations, or filter them, or fail
// with a custom error
assert violationCheckContextWithViolations.userData.executed == true
assert !violationCheckContextWithViolations.violations.isEmpty()
}
} It needs to be wired in using the richReport {
addPostProcessRule(MySetupRule)
} Avoiding multiple violations for the same classSince 0.2.5, it is now possible to track which members have already resulted in a violation.
Since rules are executed in order, and that you can have a rule applied for a status change and a generic rule applied on the same member, it was possible for a member to trigger multiple violations.
To avoid this, you can make your rule extend |
2023-10-27
2022-08-15
2022-08-17
2022-09-23
2022-08-13
请发表评论