revapi / revapi Goto Github PK

Revapi is an API analysis and change tracking tool written in Java. Its focus is mainly on Java language itself but it has been specifically designed to not be limited to just Java. API is much more than just java classes - also various configuration files, schemas, etc. can contribute to it and users can become reliant on them.

Home Page: http://revapi.org

License: Apache License 2.0

Java 97.15% Shell 0.90% CSS 0.21% Batchfile 0.04% Groovy 0.58% FreeMarker 0.19% JavaScript 0.53% Handlebars 0.40%

java api compatibility maven-plugin api-analyzer revapi

revapi's Introduction

Revapi

Table of Contents

Summary
Building
Usage
- Standalone
- Maven
- Gradle
- Embedding
Extending Revapi
Getting in touch

Revapi is a tool for API analysis and change tracking.

Summary

While Revapi is designed to be extensible and in theory should support API checks in other languages than Java (not just programming languages but anything that can be decomposed to a tree structure) the only extension in existence today is the Java API checker.

The main distinguishing features of the Java API checker include:

large number of API checks
- categorized by their influence on source, binary and "semantic" compatibility
support for computing the API "surface" by tracking usages of types across the checked library and also its dependencies (ability to report type "leakage" from deps)
powerful filtering of elements to check and reclassification of found problems
ability to filter by annotation presence
Maven plugin automatically includes dependencies in the check

Other features:

ability to judge the severity of changes based on semver rules (see here)
automatic updates of pom.xml or release.properties versions according to semver rules (see here)
pluggable reporting (standard output, maven site generation, FreeMarker templates, JSON, …)

Building

This is a maven project, so to build you simply:

mvn install

Usage

Revapi can be invoked in a couple of ways. It can be used as a standalone program, as a maven plugin or it can also be embedded in your application and used as a library.

Standalone

Download the standalone distribution zip and

unzip revapi-XXX-standalone.zip
cd revapi-XXX-standalone
./revapi.sh

Read the usage info and go.

Maven

<build>
    <plugins>
        <plugin>
            <groupId>org.revapi</groupId>
            <artifactId>revapi-maven-plugin</artifactId>
            <version>...</version>
            <dependencies>
                <dependency>
                    <groupId>org.revapi</groupId>
                    <artifactId>revapi-java</artifactId>
                    <version>...</version>
                </dependency>
                <dependency>
                    <groupId>com.acme</groupId>
                    <artifactId>my-extension</artifactId>
                    <version>...</version>
                </dependency>
                ...
            </dependencies>
            <configuration>
                ...
            </configuration>
            <executions>
                <execution>
                    <id>api-check</id>
                    <goals><goal>check</goal></goals>
                    ...
                </execution>
                ...
            </executions>
        </plugin>
        ...
    </plugins>
    ...
</build>

Gradle

There is an external Gradle plugin available for Revapi, https://github.com/palantir/gradle-revapi.

Embedding

Revapi revapi = Revapi.builder().withAllExtensionsFromThreadContextClassLoader().build();

AnalysisContext analysisContext = AnalysisContext.builder()
    .withOldAPI(API.of(...))
    .withNewAPI(API.of(...))
    .withConfigurationFromJSON("json").build();

revapi.analyze(analysisContext);

Extending Revapi

See the site for more info.

Getting in touch

Mastodon: @[email protected]
Twitter: @revapi_org
Matrix: #revapiorg:matrix.org
Mailing list: [email protected]
Issues: https://github.com/revapi/revapi/issues
Code: https://github.com/revapi/

revapi's People

Contributors

Stargazers

Watchers

revapi's Issues

False positives: enum

Revapi 0.3.1 seems to erronously warn about enums that have not changed: The enum constant was defined on position 0 but is now on 0.

The issue can be reproduced by comparing e.g. two identical GAVs:

revapi.sh -e org.revapi:revapi-java:0.3.1,org.revapi:revapi-reporting-text:0.3.1 -a io.norberg:rut:0.10 -b io.norberg:rut:0.10
Downloading: http://repo.maven.apache.org/maven2/io/norberg/rut/0.10/rut-0.10.jar
Downloaded: http://repo.maven.apache.org/maven2/io/norberg/rut/0.10/rut-0.10.jar (0 B at 0.0 KB/sec)
Downloading: http://repo.maven.apache.org/maven2/io/norberg/rut/0.10/rut-0.10.pom
Downloaded: http://repo.maven.apache.org/maven2/io/norberg/rut/0.10/rut-0.10.pom (0 B at 0.0 KB/sec)
Downloading: http://repo.maven.apache.org/maven2/org/sonatype/oss/oss-parent/9/oss-parent-9.pom
Downloaded: http://repo.maven.apache.org/maven2/org/sonatype/oss/oss-parent/9/oss-parent-9.pom (0 B at 0.0 KB/sec)
old: field io.norberg.rut.Router.Status.METHOD_NOT_ALLOWED
new: field io.norberg.rut.Router.Status.METHOD_NOT_ALLOWED
java.field.enumConstantOrderChanged BINARY: NON_BREAKING, SEMANTIC: POTENTIALLY_BREAKING, SOURCE: NON_BREAKING: The enum constant was defined on position 2 but is now on 2. The user code can break if it relies on the return value of the "ordinal()" method.

old: field io.norberg.rut.Router.Status.NOT_FOUND
new: field io.norberg.rut.Router.Status.NOT_FOUND
java.field.enumConstantOrderChanged BINARY: NON_BREAKING, SEMANTIC: POTENTIALLY_BREAKING, SOURCE: NON_BREAKING: The enum constant was defined on position 1 but is now on 1. The user code can break if it relies on the return value of the "ordinal()" method.

old: field io.norberg.rut.Router.Status.SUCCESS
new: field io.norberg.rut.Router.Status.SUCCESS
java.field.enumConstantOrderChanged BINARY: NON_BREAKING, SEMANTIC: POTENTIALLY_BREAKING, SOURCE: NON_BREAKING: The enum constant was defined on position 0 but is now on 0. The user code can break if it relies on the return value of the "ordinal()" method.

revapi gradle plugin

I didn't find any revapi gradle plugin and I'm surprised nobody asked it before, but it could be awesome to have one for gradle users.

Maven plugin not working?

If I use the configuration described in Issue #8 , I get the following error when I run mvn revapi:check -X

org.revapi:revapi-maven-plugin:0.3.1:check failed: file cannot be null
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
    ... 20 more
Caused by: java.lang.IllegalArgumentException: file cannot be null
    at org.revapi.maven.FileArchive.<init>(FileArchive.java:38)
    at org.revapi.maven.Analyzer$1.apply(Analyzer.java:208)

Configuration should be specified in XML

at least the maven plugin should understand XML configuration instead of JSON. JSON looks ugly and out of place in pom.xml.

Empty chains when reportUsesFor is turned on

Hello,

with java extension 0.11.2 + revapi 0.7.0 when I turn on "reportUsesFor": ["java.method.addedToInterface"] in report, there are no chains. It only looks like: Use chain of the type in the old API: Use chain of the type in the new API:.

Thanks.

Failed detecting return type change

In our SDK we have recently introduced code auto-generation and we decided to use Revapi Maven Plugin to make sure we were not introducing breaking changes. So far worked great, but apparently the plugin wasn't able to find a return type change which raised the nasty NoSuchMethodError exception to our SDK users under certain circumstances.

I've tried to narrow down the info as much as possible, to be able to figure out where the problem comes from. Everything relevant can be found in https://gist.github.com/lauraluiz/1cb2f1ded27bebeae37b0d0e9dda01b6, where it is analyzed the SDK from versions v1.6.0 to v1.8.0, where the change happened (in case you wonder, there is a small anomaly on the v1.7.0 Javadoc, reason why I've decided to skip it).

In particular, the return type was changed from returning an interface to returning one of the implementations. The source code remained the same, the signature didn't provide any breaking change. But then of course the Java bytecode changed and couldn't find the method's signature anymore, thus raising the NoSuchMethodError.

The report doesn't show this change though. Is it expected, a bug or did I miss something?

Latest release resolution should be more intelligent

Currently revapi just blindly uses whatever Maven resolves as the RELEASE version of the artifact.

This is problematic in some cases like:

building a site after (or during) a release with the report goal - in this case, the report goal just compares the release with itself.
some plugins, like https://github.com/l2x6/srcdeps-maven-plugin, produce artifacts that are not snapshots yet should not be considered releases. There should be some kind of regex to exclude certain version formats from being considered a release artifact. This should also help if people use -rc or .Beta artifacts that probably might not be the desired artifacts to compare against with the next release.

Failed to analyze archives: Could not find the corresponding model element for use

Hi,

On the XWiki project we're having a build failure when building https://github.com/xwiki/xwiki-platform/tree/955505595b95784876777a7059fb3bc725c01776/xwiki-platform-core/xwiki-platform-legacy/xwiki-platform-legacy-oldcore

We're getting:

[INFO] --- revapi-maven-plugin:0.4.5:check (revapi-check) @ xwiki-platform-legacy-oldcore ---
Downloading: http://nexus.xwiki.org/nexus/content/groups/public/com/sun/speech/freetts/freetts/1.2.1/freetts-1.2.1.pom
Downloading: https://repo.maven.apache.org/maven2/com/sun/speech/freetts/freetts/1.2.1/freetts-1.2.1.pom
Downloading: http://forge.octo.com/archiva/repository/3rd-party/com/sun/speech/freetts/freetts/1.2.1/freetts-1.2.1.pom
Downloading: http://repository.atlassian.com/maven2/com/sun/speech/freetts/freetts/1.2.1/freetts-1.2.1.pom
Downloading: http://svn.atlassian.com/svn/public/contrib/repository/maven2/com/sun/speech/freetts/freetts/1.2.1/freetts-1.2.1.pom
Downloading: http://nexus.xwiki.org/nexus/content/groups/public/javax/ejb/ejb/2.0/ejb-2.0.jar
Downloading: http://nexus.xwiki.org/nexus/content/groups/public/javax/faces/jsf-api/1.1/jsf-api-1.1.jar
Downloading: http://nexus.xwiki.org/nexus/content/groups/public/com/sun/speech/freetts/freetts/1.2.1/freetts-1.2.1.jar
Downloading: https://repo.maven.apache.org/maven2/javax/ejb/ejb/2.0/ejb-2.0.jar
Downloading: https://repo.maven.apache.org/maven2/javax/faces/jsf-api/1.1/jsf-api-1.1.jar
Downloading: https://repo.maven.apache.org/maven2/com/sun/speech/freetts/freetts/1.2.1/freetts-1.2.1.jar
Downloading: http://forge.octo.com/archiva/repository/3rd-party/com/sun/speech/freetts/freetts/1.2.1/freetts-1.2.1.jar
Downloading: http://repository.atlassian.com/maven2/com/sun/speech/freetts/freetts/1.2.1/freetts-1.2.1.jar
Downloading: http://svn.atlassian.com/svn/public/contrib/repository/maven2/com/sun/speech/freetts/freetts/1.2.1/freetts-1.2.1.jar
[WARNING] Failed to resolve dependencies of old artifacts: Resolution of some artifacts failed: Could not locate the file of the maven artifact: javax.faces:jsf-api:jar:1.1, Could not locate the file of the maven artifact: com.sun.speech.freetts:freetts:jar:1.2.1, Failed to read artifact descriptor for com.sun.speech.freetts:freetts:jar:1.2.1, Could not locate the file of the maven artifact: javax.ejb:ejb:jar:2.0.. The API analysis might produce unexpected results.
[WARNING] Failed to resolve dependencies of new artifacts: Resolution of some artifacts failed: Could not locate the file of the maven artifact: javax.faces:jsf-api:jar:1.1, Could not locate the file of the maven artifact: com.sun.speech.freetts:freetts:jar:1.2.1, Could not locate the file of the maven artifact: javax.ejb:ejb:jar:2.0.. The API analysis might produce unexpected results.
[INFO] Comparing [org.xwiki.platform:xwiki-platform-legacy-oldcore:jar:8.2.1] against [org.xwiki.platform:xwiki-platform-legacy-oldcore:jar:8.3-SNAPSHOT] (including their transitive dependencies).
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:12 min
[INFO] Finished at: 2016-08-19T15:55:09+02:00
[INFO] Final Memory: 122M/984M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.revapi:revapi-maven-plugin:0.4.5:check (revapi-check) on project xwiki-platform-legacy-oldcore: Failed to analyze archives: Could not find the corresponding model element for use: RawUseSite[siteClass='com.xpn.xwiki.internal.MessageToolVelocityContextInitializer', siteDescriptor='null', siteName='null', sitePosition=-1, siteType=CLASS, useType=IS_IMPLEMENTED] of type org.xwiki.velocity.VelocityContextInitializer -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.revapi:revapi-maven-plugin:0.4.5:check (revapi-check) on project xwiki-platform-legacy-oldcore: Failed to analyze archives
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:497)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to analyze archives
    at org.revapi.maven.Analyzer.analyze(Analyzer.java:309)
    at org.revapi.maven.AbstractRevapiMojo.analyze(AbstractRevapiMojo.java:199)
    at org.revapi.maven.CheckMojo.execute(CheckMojo.java:42)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
    ... 20 more
Caused by: java.lang.IllegalStateException: Could not find the corresponding model element for use: RawUseSite[siteClass='com.xpn.xwiki.internal.MessageToolVelocityContextInitializer', siteDescriptor='null', siteName='null', sitePosition=-1, siteType=CLASS, useType=IS_IMPLEMENTED] of type org.xwiki.velocity.VelocityContextInitializer
    at org.revapi.java.compilation.ProbingEnvironment.toUseSite(ProbingEnvironment.java:349)
    at org.revapi.java.compilation.ProbingEnvironment.access$000(ProbingEnvironment.java:68)
    at org.revapi.java.compilation.ProbingEnvironment$1.visit(ProbingEnvironment.java:168)
    at org.revapi.java.compilation.ProbingEnvironment.visitRawUseSites(ProbingEnvironment.java:212)
    at org.revapi.java.compilation.ProbingEnvironment.visitUseSites(ProbingEnvironment.java:160)
    at org.revapi.java.JavaElementDifferenceAnalyzer.appendUses(JavaElementDifferenceAnalyzer.java:312)
    at org.revapi.java.JavaElementDifferenceAnalyzer.endAnalysis(JavaElementDifferenceAnalyzer.java:249)
    at org.revapi.Revapi.analyze(Revapi.java:238)
    at org.revapi.Revapi.analyzeWith(Revapi.java:188)
    at org.revapi.Revapi.analyze(Revapi.java:119)
    at org.revapi.maven.Analyzer.analyze(Analyzer.java:307)
    ... 24 more
[ERROR]

Any idea?

Thanks
-Vincent

Get a summary of errors by default

It sure is nice to have all those detailed information you can just copy/paste when all you want is ignore whatever errors you have but when you actually want to know what those errors are my feeling is that I have to spend more time than I should to extract the actual information in the middle of a bunch of noise. It would be nice to have just the actual issue without detailed documentation around by default (and enable the detail with some system/pom property or something).

I come from CLIRR which I found more readable. Here is an example for the same errors (3 errors very easy to fix in Java 8 that I don't want to put in the ignored errors):

CLIRR:

[ERROR] 7012: org.xwiki.extension.job.ExtensionRequest: Method 'public boolean isRootModificationsAllowed()' has been added to an interface
[ERROR] 7012: org.xwiki.extension.ExtensionDependency: Method 'public boolean isCompatible(org.xwiki.extension.ExtensionId)' has been added to an interface
[ERROR] 7012: org.xwiki.extension.ExtensionDependency: Method 'public boolean isCompatible(org.xwiki.extension.Extension)' has been added to an interface

revapi:

[ERROR] [org.xwiki.commons:xwiki-commons-extension-api:jar:8.1-SNAPSHOT] method boolean org.xwiki.extension.ExtensionDependency::isCompatible(org.xwiki.extension.Extension): java.method.addedToInterface: Method was added to an interface.
[ERROR] If you're using the semver-ignore extension, update your module's version to one compatible with the current changes (e.g. mvn package revapi:update-versions). If you want to explicitly ignore this change and provide a justification for it, add the following JSON snippet to your Revapi configuration under "revapi.ignore" path:
[ERROR] {
[ERROR] "code": "java.method.addedToInterface",
[ERROR] "new": "method boolean org.xwiki.extension.ExtensionDependency::isCompatible(org.xwiki.extension.Extension)",
[ERROR] "justification": <<<<< ADD YOUR EXPLANATION FOR THE NECESSITY OF THIS CHANGE >>>>>
[ERROR] }
[ERROR] [org.xwiki.commons:xwiki-commons-extension-api:jar:8.1-SNAPSHOT] method boolean org.xwiki.extension.ExtensionDependency::isCompatible(org.xwiki.extension.ExtensionId): java.method.addedToInterface: Method was added to an interface.
[ERROR] If you're using the semver-ignore extension, update your module's version to one compatible with the current changes (e.g. mvn package revapi:update-versions). If you want to explicitly ignore this change and provide a justification for it, add the following JSON snippet to your Revapi configuration under "revapi.ignore" path:
[ERROR] {
[ERROR] "code": "java.method.addedToInterface",
[ERROR] "new": "method boolean org.xwiki.extension.ExtensionDependency::isCompatible(org.xwiki.extension.ExtensionId)",
[ERROR] "justification": <<<<< ADD YOUR EXPLANATION FOR THE NECESSITY OF THIS CHANGE >>>>>
[ERROR] }
[ERROR] [org.xwiki.commons:xwiki-commons-extension-api:jar:8.1-SNAPSHOT] method boolean org.xwiki.extension.job.ExtensionRequest::isRootModificationsAllowed(): java.method.addedToInterface: Method was added to an interface.
[ERROR] If you're using the semver-ignore extension, update your module's version to one compatible with the current changes (e.g. mvn package revapi:update-versions). If you want to explicitly ignore this change and provide a justification for it, add the following JSON snippet to your Revapi configuration under "revapi.ignore" path:
[ERROR] {
[ERROR] "code": "java.method.addedToInterface",
[ERROR] "new": "method boolean org.xwiki.extension.job.ExtensionRequest::isRootModificationsAllowed()",
[ERROR] "justification": <<<<< ADD YOUR EXPLANATION FOR THE NECESSITY OF THIS CHANGE >>>>>
[ERROR] }

several errors like this really makes it quite a pain to extract the actual breakages from the huge error block

Bug in revapi-java 0.11.* with FieldMovedInHierarchy

Hi,

i'm setting up revapi for Spoon project through maven plugin and it seems there's a bug with FieldMovedInHierarchy on version 0.11.1 and 0.11.2 of revapi-java. Everythings work fine with version 0.10.2.

I obtain the following error when executing check goal:

Exception in thread "main" java.util.ServiceConfigurationError: org.revapi.java.spi.Check: Provider org.revapi.java.checks.fields.FieldMovedInHierarchy could not be instantiated [...]
Caused by: java.lang.NoSuchFieldError: FIELD_INHERITED_NOW_DECLARED at org.revapi.java.checks.fields.FieldMovedInHierarchy.(FieldMovedInHierarchy.java:17)

The full stack trace is available on this gist.

Here's my maven config for revapi:

    <plugin>
        <groupId>org.revapi</groupId>
        <artifactId>revapi-maven-plugin</artifactId>
        <version>0.6.1</version>
        <dependencies>
          <dependency>
            <groupId>org.revapi</groupId>
            <artifactId>revapi-java</artifactId>
            <version>0.11.2</version>
          </dependency>
        </dependencies>
        <executions>
          <execution>
            <id>revapi-check</id>
            <goals>
              <goal>check</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <analysisConfiguration>
            {
              "revapi": {
                "java": {
                  "filter": {
                    "packages": {
                      "regex": true,
                      "include": ["spoon\\..*"],
                      "exclude": ["spoon\\..*\\.test(\\..*)?"]
                    }
                  }
                }
              }
            }
          </analysisConfiguration>
        </configuration>
      </plugin>

revapi:update-versions fails to create a new <version> element if none is present in the pom

The title says it all...

newArtifacts special BUILD value not recognised anymore

Hello, in the doc it is described the newArtifacts can have a special "BUILD" value.

Having in a pom like this:

          <oldArtifacts>
            <artifact>${project.groupId}:${project.artifactId}:1.0.0</artifact>
          </oldArtifacts>
          <newArtifacts>
            <!-- The special 'BUILD' GAV is used to specify artifacts that were produced during the build of the current project. -->
            <artifact>BUILD</artifact>
          </newArtifacts>

fails with error

[INFO] --- revapi-maven-plugin:0.5.0:check (check) @ revapi-scratchpad-build ---
[WARNING] Failed to resolve new artifacts: Bad artifact coordinates BUILD, expected format is <groupId>:<artifactId>[:<extension>[:<classifier>]]:<version>. The API analysis will not proceed.

I have a full reproducer with 2 commits, so you can even mvn install version 1.0.0 while checkingout the first commit, and check the result of the comparison and the above mentioned error while checkingout the second commit including the configuration BUILD variable above here. If that helps.

Annotation filter not behaving correctly

Hi,

I have tried to turn on annotation filter and it does not behave as expected. Here is the short reproducer:
https://github.com/MarianMacik/jbpm/tree/revapi-bug - the last commit in this branch contains changes which I deliberately made so revapi will find them. But when annotation filter is turned on (uncomment the part in JSON file which is a part of the last commit), it does not find java.annotation.attributeValueChanged change. When I comment the filter, the report will contain these changes, which is expected.

It is only enough to run mvn clean install -DskipTests in jbpm-audit module.

It behaves the same with 0.6.1 + 0.10.2 and 0.7.0 + 0.11.2 versions.

Thanks,

Marian

Memory leak in Compiler

Somehow, when used inside the maven plugin the resources of the compiler are kept in memory.

This leads to ever increasing memory usage when compiling a multimodule project.

The heapdump reveals that the cause of this is the standard file manager used by the javax.tools.JavaCompiler that has a shared static instance of a zip file index, whatever that is. Because this is loaded by the system classloader and is a static field that is used by all of the compilation runs, it just accumulates the contents of all jars that we used during the compilation.

For example on xwiki-platform this leads to more than 1GB of heap consumed only by this one field.

No violation reported for method added to interface

This is strange and I don't know if it's me doing something wrong or not.

Basically I modified the URLNormalizer interface to add a new method in order to generate a violation but running mvn clean verify -DskipTests=truein xwiki-platform/xwiki-platform-core/xwiki-platform-url/xwiki-platform-url-apigives:

[INFO] --- revapi-maven-plugin:0.4.5:check (revapi-check) @ xwiki-platform-url-api ---
[INFO] Comparing [org.xwiki.platform:xwiki-platform-url-api:jar:8.0] against [org.xwiki.platform:xwiki-platform-url-api:jar:8.1-SNAPSHOT] (including their transitive dependencies).
[INFO] API checks completed without failures.

What's even stranger is that running mvn clean verify -DskipTests=true -Dxwiki.compatibility.previous.version=6.0(i.e comparing to a very old version) also gives no errors.

Any idea?

Thanks

Avoid warning in Maven logs for non java modules

I see in my logs:

[INFO] --- revapi-maven-plugin:0.4.2:check (revapi-check) @ xwiki-platform-core ---
[INFO] Comparing [org.xwiki.platform:xwiki-platform-core:pom:7.4.2] against [org.xwiki.platform:xwiki-platform-core:pom:8.1-SNAPSHOT] (including their transitive dependencies).
[INFO] Unsupported type of data - neither a Java class file or a JAR file: org.xwiki.platform:xwiki-platform-core:pom:7.4.2
[INFO] Unsupported type of data - neither a Java class file or a JAR file: org.xwiki.platform:xwiki-platform-core:pom:8.1-SNAPSHOT
[INFO] API checks completed without failures.

It would be nice if there was a way to tell revapi to not even try to execute on some packaging (like pom packagings). This could speed up the build and also avoid the extra output in the console.

Convert to strictly using ASM or Javassist instead of using javax.tools.JavaCompiler

The advantage of having the java compiler produce the code model is diminished by a these two main factors:

hard to parallelize - javac doesn't allow concurrent (first) access. it reads the code lazily and if two threads read the same part of code for the first time, it complains loudly
comparably slow - need to scan the archives using ASM and only THEN have the compiler produce the model on the codebase that's already been scanned.

Solutions:

use javassist's /asm's code model
- pros: no double scanning
- cons: large rewrite of all checks, lack of goodies from javax.lang.model.ElementUtils and TypeUtils
create a library on top of javassist/asm that would implement javax.lang model:
- pros: no need to rewrite the checks
- cons: a lot of work

Documentation errors for maven plugin

The examples at this page don't appear to work. http://revapi.org/generated/revapi-maven-plugin/examples.html

I believe that plugin dependencies need to go in the <pluginManagement>

<pluginManagement>
  <plugins>
    <plugin>
        <groupId>org.revapi</groupId>
        <artifactId>revapi-maven-plugin</artifactId>
        <version>0.3.1</version>
        <dependencies>
            <dependency>
                <groupId>org.revapi</groupId>
                <artifactId>revapi-java</artifactId>
                <version>0.3.1</version>
            </dependency>
        </dependencies>
    </plugin>             
  </plugins>
</pluginManagement>

When Specifying Old And New Versions I think they need to go in a <configuration>

<plugin>
    <groupId>org.revapi</groupId>
    <artifactId>revapi-maven-plugin</artifactId>
    <version>0.3.1</version>
    <configuration>
        <oldArtifacts>
            <artifact>${project.groupId}:${project.artifactId}:${comparison.version}</artifact>
        </oldArtifacts>
        <newArtifacts>
            <artifact>${project.groupId}:${project.artifactId}:${new.version}</artifact>
        </newArtifacts>             
    </configuration>
</plugin>

Generate JUnit compatible XML report

We use the revapi-maven-plugin and execute it as part of Maven build in Jenkins. When there are incompatibilities found, the whole build will fail (Jenkins marks that with red color).

It would great if the plugin (or directly revapi) could report the fails as failed test cases in the JUnit compatible format, so that Jenkins could pick that up and create nice report. Then Jenkins would mark the build as unstable (yellow) instead of failed (red). This would make it easy to see if the build failed because of some maven related error, or because some of the checks failed (e.g. revapi, animal-sniffer, etc).

Here is some info about how the JUnit XML format looks: http://stackoverflow.com/questions/4922867/junit-xml-format-specification-that-hudson-supports

Add a warning/throw an exception when there are no API analyzers configured

Because without API analyzers, Revapi does nothing. This should also help people when the forget/omit to add the api analyzer as a dependency of the maven plugin.

Add support for Java 9

I know Java 9 is far from final, but because I want to be a good Java citizen I am trying the EA builds with our projects to make sure they work as expected (and potentially report bugs if they don't).

Currently I am getting the following error from revapi:

[ERROR] Failed to execute goal org.revapi:revapi-maven-plugin:0.4.1:report (report) on project kie-api: Execution report of goal org.revapi:revapi-maven-plugin:0.4.1:report failed: Failed to generate report. Failed to analyze archives: Failed to obtain class tree due to compilation failure. Compilation failed while analyzing API[...]:
[ERROR] warning: Supported source version 'RELEASE_8' from annotation processor 'org.revapi.java.compilation.ProbingAnnotationProcessor' less than -source '1.9'

It would be great if revapi could support Java 9.

Inconsistent sorting of methods

@vmassol discovered this:

Specifically, running mvn clean verify -Dxwiki.clirr.skip=true in xwiki-platform/xwiki-platform-core/xwiki-platform-legacy/xwiki-platform-legacy-oldcorefails for me with:

[ERROR] Failed to execute goal org.revapi:revapi-maven-plugin:0.4.2:check (revapi-check) on project xwiki-platform-legacy-oldcore: The following API problems caused the build to fail:
[ERROR] [org.xwiki.platform:xwiki-platform-legacy-oldcore:jar:7.4.2] method java.lang.String com.xpn.xwiki.doc.XWikiDocument::getContentOfSection(int) throws com.xpn.xwiki.XWikiException: java.method.removed: Method was removed.
[ERROR] If you're using the semver-ignore extension, update your module's version to one compatible with the current changes (e.g. mvn package revapi:update-versions). If you want to explicitly ignore this change and provide a justification for it, add the following JSON snippet to your Revapi configuration under "revapi.ignore" path:
[ERROR] {
[ERROR] "code": "java.method.removed",
[ERROR] "old": "method java.lang.String com.xpn.xwiki.doc.XWikiDocument::getContentOfSection(int) throws com.xpn.xwiki.XWikiException",
[ERROR] "justification": <<<<< ADD YOUR EXPLANATION FOR THE NECESSITY OF THIS CHANGE >>>>>
[ERROR] }
[ERROR] [org.xwiki.platform:xwiki-platform-legacy-oldcore:jar:7.4.2] method java.util.List<com.xpn.xwiki.api.DocumentSection> com.xpn.xwiki.doc.XWikiDocument::getSections() throws com.xpn.xwiki.XWikiException: java.method.removed: Method was removed.
[ERROR] If you're using the semver-ignore extension, update your module's version to one compatible with the current changes (e.g. mvn package revapi:update-versions). If you want to explicitly ignore this change and provide a justification for it, add the following JSON snippet to your Revapi configuration under "revapi.ignore" path:
[ERROR] {
[ERROR] "code": "java.method.removed",
[ERROR] "old": "method java.util.List<com.xpn.xwiki.api.DocumentSection> com.xpn.xwiki.doc.XWikiDocument::getSections() throws com.xpn.xwiki.XWikiException",
[ERROR] "justification": <<<<< ADD YOUR EXPLANATION FOR THE NECESSITY OF THIS CHANGE >>>>>
[ERROR] }
[ERROR] [org.xwiki.platform:xwiki-platform-legacy-oldcore:jar:7.4.2] method java.util.Set<java.lang.String> com.xpn.xwiki.doc.XWikiDocument::getUniqueLinkedPages(com.xpn.xwiki.XWikiContext): java.method.removed: Method was removed.
[ERROR] If you're using the semver-ignore extension, update your module's version to one compatible with the current changes (e.g. mvn package revapi:update-versions). If you want to explicitly ignore this change and provide a justification for it, add the following JSON snippet to your Revapi configuration under "revapi.ignore" path:
[ERROR] {
[ERROR] "code": "java.method.removed",
[ERROR] "old": "method java.util.Set<java.lang.String> com.xpn.xwiki.doc.XWikiDocument::getUniqueLinkedPages(com.xpn.xwiki.XWikiContext)",
[ERROR] "justification": <<<<< ADD YOUR EXPLANATION FOR THE NECESSITY OF THIS CHANGE >>>>>
[ERROR] }
[ERROR] [org.xwiki.platform:xwiki-platform-legacy-oldcore:jar:7.4.2] method void com.xpn.xwiki.doc.XWikiDocument::setMinorEdit(boolean): java.method.removed: Method was removed.
[ERROR] If you're using the semver-ignore extension, update your module's version to one compatible with the current changes (e.g. mvn package revapi:update-versions). If you want to explicitly ignore this change and provide a justification for it, add the following JSON snippet to your Revapi configuration under "revapi.ignore" path:
[ERROR] {
[ERROR] "code": "java.method.removed",
[ERROR] "old": "method void com.xpn.xwiki.doc.XWikiDocument::setMinorEdit(boolean)",
[ERROR] "justification": <<<<< ADD YOUR EXPLANATION FOR THE NECESSITY OF THIS CHANGE >>>>>
[ERROR] }
[ERROR] [org.xwiki.platform:xwiki-platform-legacy-oldcore:jar:7.4.2] method java.lang.String com.xpn.xwiki.doc.XWikiDocument::updateDocumentSection(int, java.lang.String) throws com.xpn.xwiki.XWikiException: java.method.removed: Method was removed.
[ERROR] If you're using the semver-ignore extension, update your module's version to one compatible with the current changes (e.g. mvn package revapi:update-versions). If you want to explicitly ignore this change and provide a justification for it, add the following JSON snippet to your Revapi configuration under "revapi.ignore" path:
[ERROR] {
[ERROR] "code": "java.method.removed",
[ERROR] "old": "method java.lang.String com.xpn.xwiki.doc.XWikiDocument::updateDocumentSection(int, java.lang.String) throws com.xpn.xwiki.XWikiException",
[ERROR] "justification": <<<<< ADD YOUR EXPLANATION FOR THE NECESSITY OF THIS CHANGE >>>>>
[ERROR] }
[ERROR] [org.xwiki.platform:xwiki-platform-legacy-oldcore:jar:7.4.2] method java.lang.String com.xpn.xwiki.doc.XWikiDocumentCompatibilityAspect::ajc$interMethod$com_xpn_xwiki_doc_XWikiDocumentCompatibilityAspect$com_xpn_xwiki_doc_XWikiDocument$extractTitle(com.xpn.xwiki.doc.XWikiDocument): java.method.removed: Method was removed.
[ERROR] If you're using the semver-ignore extension, update your module's version to one compatible with the current changes (e.g. mvn package revapi:update-versions). If you want to explicitly ignore this change and provide a justification for it, add the following JSON snippet to your Revapi configuration under "revapi.ignore" path:
[ERROR] {
[ERROR] "code": "java.method.removed",
[ERROR] "old": "method java.lang.String com.xpn.xwiki.doc.XWikiDocumentCompatibilityAspect::ajc$interMethod$com_xpn_xwiki_doc_XWikiDocumentCompatibilityAspect$com_xpn_xwiki_doc_XWikiDocument$extractTitle(com.xpn.xwiki.doc.XWikiDocument)",
[ERROR] "justification": <<<<< ADD YOUR EXPLANATION FOR THE NECESSITY OF THIS CHANGE >>>>>
[ERROR] }
[ERROR] [org.xwiki.platform:xwiki-platform-legacy-oldcore:jar:7.4.2] method org.suigeneris.jrcs.rcs.Version com.xpn.xwiki.doc.rcs.XWikiRCSNodeId::getVersion(): java.method.removed: Method was removed.
[ERROR] If you're using the semver-ignore extension, update your module's version to one compatible with the current changes (e.g. mvn package revapi:update-versions). If you want to explicitly ignore this change and provide a justification for it, add the following JSON snippet to your Revapi configuration under "revapi.ignore" path:
[ERROR] {
[ERROR] "code": "java.method.removed",
[ERROR] "old": "method org.suigeneris.jrcs.rcs.Version com.xpn.xwiki.doc.rcs.XWikiRCSNodeId::getVersion()",
[ERROR] "justification": <<<<< ADD YOUR EXPLANATION FOR THE NECESSITY OF THIS CHANGE >>>>>
[ERROR] }
[ERROR] [org.xwiki.platform:xwiki-platform-legacy-oldcore:jar:7.4.2] method void com.xpn.xwiki.doc.rcs.XWikiRCSNodeId::setVersion(org.suigeneris.jrcs.rcs.Version): java.method.removed: Method was removed.
[ERROR] If you're using the semver-ignore extension, update your module's version to one compatible with the current changes (e.g. mvn package revapi:update-versions). If you want to explicitly ignore this change and provide a justification for it, add the following JSON snippet to your Revapi configuration under "revapi.ignore" path:
[ERROR] {
[ERROR] "code": "java.method.removed",
[ERROR] "old": "method void com.xpn.xwiki.doc.rcs.XWikiRCSNodeId::setVersion(org.suigeneris.jrcs.rcs.Version)",
[ERROR] "justification": <<<<< ADD YOUR EXPLANATION FOR THE NECESSITY OF THIS CHANGE >>>>>
[ERROR] }
[ERROR] [org.xwiki.platform:xwiki-platform-legacy-oldcore:jar:7.4.2] class com.xpn.xwiki.plugin.diff.DiffPlugin: java.class.removed: Class was removed.
[ERROR] If you're using the semver-ignore extension, update your module's version to one compatible with the current changes (e.g. mvn package revapi:update-versions). If you want to explicitly ignore this change and provide a justification for it, add the following JSON snippet to your Revapi configuration under "revapi.ignore" path:
[ERROR] {
[ERROR] "code": "java.class.removed",
[ERROR] "old": "class com.xpn.xwiki.plugin.diff.DiffPlugin",
[ERROR] "justification": <<<<< ADD YOUR EXPLANATION FOR THE NECESSITY OF THIS CHANGE >>>>>
[ERROR] }
[ERROR] [org.xwiki.platform:xwiki-platform-legacy-oldcore:jar:7.4.2] class com.xpn.xwiki.plugin.diff.DiffPluginApi: java.class.removed: Class was removed.
[ERROR] If you're using the semver-ignore extension, update your module's version to one compatible with the current changes (e.g. mvn package revapi:update-versions). If you want to explicitly ignore this change and provide a justification for it, add the following JSON snippet to your Revapi configuration under "revapi.ignore" path:
[ERROR] {
[ERROR] "code": "java.class.removed",
[ERROR] "old": "class com.xpn.xwiki.plugin.diff.DiffPluginApi",
[ERROR] "justification": <<<<< ADD YOUR EXPLANATION FOR THE NECESSITY OF THIS CHANGE >>>>>
[ERROR] }
[ERROR] [org.xwiki.platform:xwiki-platform-legacy-oldcore:jar:7.4.2] method java.lang.String com.xpn.xwiki.web.DeleteVersionsForm::getRev(): java.method.removed: Method was removed.
[ERROR] If you're using the semver-ignore extension, update your module's version to one compatible with the current changes (e.g. mvn package revapi:update-versions). If you want to explicitly ignore this change and provide a justification for it, add the following JSON snippet to your Revapi configuration under "revapi.ignore" path:
[ERROR] {
[ERROR] "code": "java.method.removed",
[ERROR] "old": "method java.lang.String com.xpn.xwiki.web.DeleteVersionsForm::getRev()",
[ERROR] "justification": <<<<< ADD YOUR EXPLANATION FOR THE NECESSITY OF THIS CHANGE >>>>>
[ERROR] }
[ERROR] -> [Help 1]

At least for the method java.lang.String com.xpn.xwiki.doc.XWikiDocument::getContentOfSection(int) throws com.xpn.xwiki.XWikiException this is caused by incosistent sorting of the methods in the class between old and new version of the API. Coiterator then doesn't match these and thus Revapi thinks this is a removal.

moving methods to super interface inducing false positive errors for method removed

In version 1.0.0 I have an interface like this

public interface MyInterface {
    void method1();
    void method2();
}

In version 1.1.0 I create a superinterface and I move method2 from MyInterface to the superinterface

public interface SuperInterface {
    void method2();
}
public interface MyInterface extends SuperInterface {
    void method1();

}

now, from a MyInterface point of view, it is still exposing the two methods, the only difference that method1 is exposed directly, the method2 is inherited by the superinterface. From a client point of view using the MyInterface, these still have both the methods.

However I get a failure like:

[ERROR] Failed to execute goal org.revapi:revapi-maven-plugin:0.5.0:check (check) on project revapi-scratchpad-superinterface: The following API problems caused the build to fail:
[ERROR] java.method.removed: method void net.tarilabs.scratchpad.revapi_scratchpad_superinterface.MyInterface::method2(): Method was removed.
[ERROR]

which is a false positive for the reasons above.

This are my revapi versions in pom:

        <plugin>
          <groupId>org.revapi</groupId>
          <artifactId>revapi-maven-plugin</artifactId>
          <version>0.5.0</version>
          <dependencies>
            <dependency>
              <groupId>org.revapi</groupId>
              <artifactId>revapi-java</artifactId>
              <version>0.10.0</version>
            </dependency>
          </dependencies>

I have a full reproducer with 2 commits, so you can even "mvn install" version 1.0.0 while checkingout the first commit, and check the result of the comparison with version 1.1.0 to display the above mentioned error, while checkingout the second commit which moves the method2 to the superinterface. If that helps.

visibility reduced in a private class

This looks strange. when running revapi this morning I get:

[ERROR] Failed to execute goal org.revapi:revapi-maven-plugin:0.4.3:check (revapi-check) on project xwiki-commons-logging-api: The following API problems caused the build to fail:
[ERROR] [org.xwiki.commons:xwiki-commons-logging-api:jar:8.1-SNAPSHOT] method void org.xwiki.logging.LogTreeNode.LogTreeNodeIterator::<init>(java.util.Iterator<org.xwiki.logging.event.LogEvent>): java.method.visibilityReduced: visibility reduced
[ERROR] If you're using the semver-ignore extension, update your module's version to one compatible with the current changes (e.g. mvn package revapi:update-versions). If you want to explicitly ignore this change and provide a justification for it, add the following JSON snippet to your Revapi configuration under "revapi.ignore" path:
[ERROR] {
[ERROR] "code": "java.method.visibilityReduced",
[ERROR] "old": "method void org.xwiki.logging.LogTreeNode.LogTreeNodeIterator::<init>(java.util.Iterator<org.xwiki.logging.event.LogEvent>)",
[ERROR] "new": "method void org.xwiki.logging.LogTreeNode.LogTreeNodeIterator::<init>(java.util.Iterator<org.xwiki.logging.event.LogEvent>)",
[ERROR] "justification": <<<<< ADD YOUR EXPLANATION FOR THE NECESSITY OF THIS CHANGE >>>>>
[ERROR] }

Indeed the visibility has been reduced from "public" to package: xwiki/xwiki-commons@8c60c7c#diff-6bc94a3a8724b43ea7df8982ad8b13afL46

However this class where it happened is private: https://github.com/xwiki/xwiki-commons/blob/8c60c7c83bfd443e613e2371129d2b86a0f67047/xwiki-commons-core/xwiki-commons-logging/xwiki-commons-logging-api/src/main/java/org/xwiki/logging/LogTreeNode.java#L40

Could you confirm that this is a bug? Thanks

Make maven plugin's report goal report the justifications for changes.

It'll have to disable the ignore extension and read its configuration.

This is kinda breaking, because people by now are probably used to using 2 different configurations for check and report goals.

Also, this ties in with #17 - the matching has its issues.

Beef up element matching

Currently the matching of old and new elements in certain extensions (like ignore or filter) is done in place and using either string or regex matching on the human readable representations of the elements.

This is not sufficient for changes like noLongerImplementsInterface because the interfaces in question are not part of the human readable representation of the elements.

The matchers should be new type of extensions provided by the API analyzers and used by other extensions that need to match elements.

For a single element type there could be several matchers available that would be discriminated by type. I.e. you could still match the element by full text match with the human readable repre or a regex of thereof or use the more advanced API-analyzer-provided stuff.

Option to fail the build when the artifact to compare to isn't found

I get:

[INFO] --- revapi-maven-plugin:0.4.1:check (revapi-check) @ xwiki-rendering-archetype-macro ---
Downloading: http://nexus.xwiki.org/nexus/content/groups/public/org/xwiki/rendering/xwiki-rendering-archetype-macro/7.4.2/xwiki-rendering-archetype-macro-7.4.2.maven-archetype
Downloading: https://repo.maven.apache.org/maven2/org/xwiki/rendering/xwiki-rendering-archetype-macro/7.4.2/xwiki-rendering-archetype-macro-7.4.2.maven-archetype
[WARNING] Failed to resolve old artifacts: Could not find artifact org.xwiki.rendering:xwiki-rendering-archetype-macro:maven-archetype:7.4.2 in xwiki-releases (http://nexus.xwiki.org/nexus/content/groups/public). The API analysis will not proceed.
org.revapi.maven.Analyzer$MarkerException: Could not find artifact org.xwiki.rendering:xwiki-rendering-archetype-macro:maven-archetype:7.4.2 in xwiki-releases (http://nexus.xwiki.org/nexus/content/groups/public)
    at org.revapi.maven.Analyzer$2.apply(Analyzer.java:255)
    at org.revapi.maven.Analyzer$2.apply(Analyzer.java:248)
    at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
    at java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
    at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
    at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
    at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
    at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
    at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
    at org.revapi.maven.Analyzer.resolveArtifacts(Analyzer.java:273)
    at org.revapi.maven.Analyzer.analyze(Analyzer.java:320)
    at org.revapi.maven.AbstractRevapiMojo.analyze(AbstractRevapiMojo.java:181)
    at org.revapi.maven.CheckMojo.execute(CheckMojo.java:42)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:497)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.eclipse.aether.resolution.ArtifactResolutionException: Could not find artifact org.xwiki.rendering:xwiki-rendering-archetype-macro:maven-archetype:7.4.2 in xwiki-releases (http://nexus.xwiki.org/nexus/content/groups/public)
    at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:444)
    at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246)
    at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223)
    at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:294)
    at org.revapi.maven.utils.ArtifactResolver.resolveArtifact(ArtifactResolver.java:62)
    at org.revapi.maven.Analyzer$BuildAwareArtifactResolver.resolveArtifact(Analyzer.java:448)
    at org.revapi.maven.Analyzer$2.apply(Analyzer.java:252)
    ... 34 more
Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact org.xwiki.rendering:xwiki-rendering-archetype-macro:maven-archetype:7.4.2 in xwiki-releases (http://nexus.xwiki.org/nexus/content/groups/public)
    at org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:39)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:355)
    at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:581)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:249)
    at org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:520)
    at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:421)
    ... 40 more
[INFO] API checks completed without failures.

But this is not failiing the build so it'll go mostly unnoticed. I'd like an option to have the build fail. Is that possible? :) Thanks!

Method correspondence is overly simplistic

Currently the correspondence of methods from the two versions of the API is based purely on the containing type and method name.

This is overly simplistic in presence of overloaded methods where we don't always find the closest match and might report false positives or worse miss API changes altogether.

Aggregated plain text report for copy-pasting in release notes

On the XWiki project, we put all backward compatibility violations in our Release not'es. For example this is what we had for our last release that was using CLIRR: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki80#HAPIBreakages

Now that we'd like to move to revapi we need a simple way to generate such a report (without having to manually go over the logs of the hundreds of maven modules that we have).

This is currently our process for generating those CLIRR reports during a release:
http://dev.xwiki.org/xwiki/bin/view/ReleasePlans/ReleasePlanHelp#HManually

Namely:

Find all places where we have clirr excludes in our poms and remove them (so that violations are genertaed)
run clirr on all modules and output the result in a file for each module
aggregate the content from all those violations and copy paste in our releases notes by manually matching the justifications for the excludes

Do you think you could help us come up with a better automated solution with revapi?

What would help I guess is the ability to generate an aggregated (as in maven reactor) plain text report of violations for all modules and without having to remove the violations

Thanks a lot

BTW when I run "mvn clean reapi:report" from the command line on xwiki-commons/xwiki-commons-core/xwiki-commons-component, I get:

[ERROR] Failed to execute goal org.revapi:revapi-maven-plugin:0.4.2:report (default-cli) on project xwiki-commons-component-api: Execution default-cli of goal org.revapi:revapi-maven-plugin:0.4.2:report failed. NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.revapi:revapi-maven-plugin:0.4.2:report (default-cli) on project xwiki-commons-component-api: Execution default-cli of goal org.revapi:revapi-maven-plugin:0.4.2:report failed.
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:497)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-cli of goal org.revapi:revapi-maven-plugin:0.4.2:report failed.
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
    ... 20 more
Caused by: java.lang.NullPointerException
    at org.revapi.maven.ReportMojo.getDescription(ReportMojo.java:263)
    at org.revapi.maven.ReportMojo.executeReport(ReportMojo.java:235)
    at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:255)
    at org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:143)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
    ... 21 more

Support multiple configurations per extension

or rather multiple differently configured extensions of the same type in a single analysis run.

This should be helpful in cases where people would like to for example have multiple differently configured outputs.

Maven plugin could then learn to exclude certain configurations which could provide a way to implement the suggestions of @vmassol in #29 (comment) without resorting to hacks like masking subsets of extension-specific configuration (by having their ignores split into multiple configurations and then picking and choosing some of them however they wish).

This should probably be implemented together with #19.

Removed private inner classes reported.

This should not be the case, the classes are not part of the API.

No documentation for "ability to filter by annotation presence" feature

I'm currently comparing different java API compatibility checkers, and I found revapi interesting because it seems to support exclusion/inclusion for the API check based on annotations.

However, I didn't find any documentation how to use it.

Support Java8

Add option to not validate dependencies

When using the maven plugin, it would be nice to have an option so that revapi doesn't check for violations in dependencies.

Right now we have an issue in XWiki where we have one module in xwiki-commons that has violations. So we've added ignores there. However when we build some modules of xwiki-platform that depend on this module they also fail because of the violations. We don't want that since the violations are already known and ignored in xwiki-commons.

I've quickly checked CheckMojo.java but couldn't find a way to tell revapi to not check dependencies. Is that possible, maybe in the configuration file? BTW I couldn't find in the doc a single document providing all the options available to use in the configuration file, does that exist? (I found several different pages but no reference documentation).

Thanks!

Wrong method parameter change indication

Revapi labeled wrong parameters when parameter changed package.

getAssociation(TraversalContext<BE, ?> context, 
                         Query sourceQuery,
                         Class<? extends Entity<?, ?>> sourceType, 
                         Query targetQuery,
                         Class<? extends Entity<?, ?>> targetType,
                         String rel)

Query class changed package.

Details:
Query class changed package from

org.hawkular.inventory.base.Query

org.hawkular.inventory.api.Query.

https://github.com/pavolloffay/hawkular-inventory/blob/HWKINVENT-163/hawkular-inventory-api/src/main/java/org/hawkular/inventory/base/Util.java#L224

[ERROR] [org.hawkular.inventory:hawkular-inventory-api:jar:0.13.0.Final-SNAPSHOT] method parameter <BE> org.hawkular.inventory.api.model.Relationship org.hawkular.inventory.base.Util::getAssociation(org.hawkular.inventory.base.TraversalContext<BE, ?>, org.hawkular.inventory.api.Query, ===java.lang.Class<? extends org.hawkular.inventory.api.model.Entity<?===, ?>>, org.hawkular.inventory.api.Query, java.lang.Class<? extends org.hawkular.inventory.api.model.Entity<?, ?>>, java.lang.String): java.method.parameterTypeChanged: The type of the parameter changed from 'org.hawkular.inventory.base.Query' to 'org.hawkular.inventory.api.Query'.

[ERROR] [org.hawkular.inventory:hawkular-inventory-api:jar:0.13.0.Final-SNAPSHOT] method parameter <BE> org.hawkular.inventory.api.model.Relationship org.hawkular.inventory.base.Util::getAssociation(org.hawkular.inventory.base.TraversalContext<BE, ===?>===,org.hawkular.inventory.api.Query, java.lang.Class<? extends org.hawkular.inventory.api.model.Entity<?, ?>>, org.hawkular.inventory.api.Query, java.lang.Class<? extends org.hawkular.inventory.api.model.Entity<?, ?>>, java.lang.String): java.method.parameterTypeChanged: The type of the parameter changed from 'org.hawkular.inventory.base.Query' to 'org.hawkular.inventory.api.Query'.

<version.org.revapi.revapi-maven-plugin>0.3.10</version.org.revapi.revapi-maven-plugin>
<version.org.revapi.revapi-java>0.5.2</version.org.revapi.revapi-java>

Use "latest release older than the current" as the default with no config rather than strictly the latest version.

This can come in handy on maintenance branches of older releases.

Possible wrong incompatibility being reported when a method is moved to an abstract class

I got the following error:

[ERROR] [org.xwiki.platform:xwiki-platform-flavor-api:jar:7.4.2] method java.lang.Exception org.xwiki.platform.flavor.script.FlavorManagerScriptService::getLastError(): java.method.removed: Method was removed.
[ERROR] If you're using the semver-ignore extension, update your module's version to one compatible with the current changes (e.g. mvn package revapi:update-versions). If you want to explicitly ignore this change and provide a justification for it, add the following JSON snippet to your Revapi configuration under "revapi.ignore" path:
[ERROR] {
[ERROR] "code": "java.method.removed",
[ERROR] "old": "method java.lang.Exception org.xwiki.platform.flavor.script.FlavorManagerScriptService::getLastError()",
[ERROR] "justification": <<<<< ADD YOUR EXPLANATION FOR THE NECESSITY OF THIS CHANGE >>>>>
[ERROR] }

What happens is this: xwiki/xwiki-platform@41ad63e#diff-45cc9b983d6271cb79e37dbfdda880a3L46

Namely, we had:

public class FlavorManagerScriptService implements ScriptService

And we’ve modified ot to be:

public class FlavorManagerScriptService extends AbstractExtensionScriptService

While doing so we’ve removed public Exception getLastError() since it’s now already in AbstractExtensionScriptService.

I don’t understand why revapi is considering this a breaking change. Any idea?

Broken links on site for mailing lists

See http://revapi.org/modules/revapi-maven-plugin/mail-lists.html
and http://revapi.org/modules/revapi/mail-lists.html

The Subscribe link (https://groups.google.com/groups/revapi)
and the Archive link (https://groups.google.com/groups/revapi)
give this error:

"404. That’s an error.
The requested URL was not found on this server. That’s all we know."

This link does work: https://groups.google.com/forum/#!forum/revapi

[Idea] Allow storing of analysis configuration externally

Right now the analysisConfigurationFiles config section takes paths or files:

<analysisConfigurationFiles>
            <file>${project.basedir}/config/filter.json</file>
            <file>${project.basedir}/config/ignore.json</file>
            <file>
              <path>${project.basedir}/config/json-data-for-many-things.json</path>
              <roots>
                <root>configuration/revapi</root>
              </roots>
            </file>
        </analysisConfigurationFiles>

It would be nice to refactor the code at

revapi/revapi-maven-plugin/src/main/java/org/revapi/maven/Analyzer.java

Line 322 in eb7d36d

 private void gatherConfig(AnalysisContext.Builder ctxBld) throws MojoExecutionException { 

to support URLs, which are more generic than File (a file can be specified as file:///...).

This would allow storing the analysis configuration externally. One example would be to store it in a wiki page. This could make it simpler to edit and generate reports from it directly inside the wiki.

Feature: compare api against a snapshot with maven plugin

Hi,

I'm not sure if the feature is already supported or not, so if it is just close the ticket here and answer on my stackoverflow question :)

I want to be able to compare the last build against the last snapshot uploaded on our snapshot repository: the idea is to automatically detect regressions from build to build in our jenkins. However I have the impress that currently revapi only gets the last release and is not able to get last snapshots, or at least I did not find how to do that on the doc.

My current config is the following:

 <plugin>
        <groupId>org.revapi</groupId>
        <artifactId>revapi-maven-plugin</artifactId>
        <version>0.7.0</version>
        <dependencies>
          <dependency>
            <groupId>org.revapi</groupId>
            <artifactId>revapi-java</artifactId>
            <version>0.11.2</version>
          </dependency>
        </dependencies>
        <executions>
          <execution>
            <id>revapi-check</id>
            <goals>
              <goal>check</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <alwaysCheckForReleaseVersion>false</alwaysCheckForReleaseVersion>
          <oldVersion>LATEST</oldVersion>
          <analysisConfiguration>
            {
              "revapi": {
                "java": {
                  "filter": {
                    "packages": {
                      "regex": true,
                      "include": ["spoon\\..*"],
                      "exclude": ["spoon\\..*\\.test(\\..*)?"]
                    }
                  }
                }
              }
            }
          </analysisConfiguration>
        </configuration>
      </plugin>
    </plugins>

Exclude checks on transitive dependencies when the class being checked is excluded

See #30 (comment) and below

Inclusion of BOM in maven plugin causes dep overrides in extensions used by maven plugin users

Example:
BOM-X:

revapi-java = a.b.c
revapi-java-spi = a.b.c

BOM-Y:

revapi-java = a.b.d
revapi-java-spi = a.b.d

maven-plugin-X:

BOM-X

maven-plugin-Y:

BOM-Y

Now when user wants to use:

<plugin>
   <groupId>org.revapi</groupId>
   <artifactId>revapi-maven-plugin</artifactId>
   <version>X</version>
   <dependency>
      <groupId>org.revapi</groupId>
      <artifactId>revapi-java</artifactId>
      <version>a.b.d</version>
   </dependency>
</plugin>

The resulting revapi-java-spi version used by the plugin is a.b.c despite the fact that revapi-java:a.b.d depends on another version. This is probably because BOM-X used by revapi-maven-plugin in version X declares the revapi-java-spi version to a.b.c.

"Abstract method added" reported incorrectly on a public method of a private superclass if all public subclasses are concrete

This should basically degrade into java.method.added on the concrete sub classes and not be reported as error.

Generally speaking, when computing accessibility, revapi should check if a method is overridden in all accessible subclasses - if it is, then the method in the private superclass should not be marked as accessible and the methods in subclasses should "act in its name".

Handle spaces in JDK-provided paths

Public methods/fields of private super classes are not taken into account when computing the API "surface"

private class SuperClass {
   public SuperClass me;
}

public class SubClass extends SuperClass {
}

SuperClass is not reported as non-public type part of the API.

Check enum constants order

Changing the order of the constants can break semantics of the user code.

Semver-respecting failSeverity

It would be nice to have special failSeverity in maven plugin configuration that would fail the build only if changes to API does not allow current project version according to semver. In other words, current project version would define which actual failSeverity is used.

Lets say that the latest release for some project is 1.2.1, and current snapshot version declared in POM is 1.2.2-SNAPSHOT. When using this special failSeverity this build would fail if there where any non-breaking changes.

But lets say that user skips versions and goes straight to 1.3.0-SNAPSHOT, for example using revapi:update-versions. Then, without editing pom and changing failSeverity, the build would pass with non-breaking changes, but still fail for breaking changes. If the version where updated to 2.0.0-SNAPSHOT, and still using same failSeverity the build would always pass.

Ability to specify the artifact to compare to in a generic way a the top level POM

It's almost possible with:

<oldArtifacts>
<artifact>${project.groupId}:${project.artifactId}:${project.packaging}:${xwiki.compatibility.previous.version}</artifact>
</oldArtifacts>

However this will fail for example if the packaging is of type "maven-archetype" (this packaging produces jar files). Right now this forces to override the config in each module having a packaging type that doesn't result in an artifact extension named after the packaging name.

Some Java classes are checked even if though the package filter is specified

Hi,

I am getting these changes in some of my projects:
{
"code": "java.missing.newClass",
"new": "missing-class com.google.errorprone.annotations.CanIgnoreReturnValue",
"justification": "ADD YOUR EXPLANATION FOR THE NECESSITY OF THIS CHANGE"
},
{
"code": "java.missing.oldClass",
"old": "missing-class sun.util.locale.provider.LocaleServiceProviderPool.LocalizedObjectGetter",
"new": "missing-class sun.util.locale.provider.LocaleServiceProviderPool.LocalizedObjectGetter",
"justification": "Probably a bug in revapi, nothing serious"
},
{
"code": "java.missing.newClass",
"old": "missing-class sun.util.locale.provider.LocaleServiceProviderPool.LocalizedObjectGetter",
"new": "missing-class sun.util.locale.provider.LocaleServiceProviderPool.LocalizedObjectGetter",
"justification": "Probably a bug in revapi, nothing serious"
}

It is strange, because I do not have these packages specified in my filter. The config can be found here:
https://github.com/MarianMacik/optaplanner/blob/revapi/optaplanner-core/src/build/revapi-config.json#L1158

The error details are: java.missing.oldClass: missing-class sun.util.locale.provider.LocaleServiceProviderPool.LocalizedObjectGetter: Class 'sun.util.locale.provider.LocaleServiceProviderPool.LocalizedObjectGetter' could not be found in the archives of the old API. It has been detected as contributing to the API and thus the analysis results may be incorrect.
[ERROR] Use chain of the type in the old API:
[ERROR] Use chain of the type in the new API:

Chains are empty even after I turn on "reportUsesFor": ["java.missing.newClass", "java.missing.oldClass"], but this is already documented in #46.