These settings take precedence over the configuration loaded from analysisConfigurationFiles.

The analysisConfiguration can override the settings present in the files.

The list is either a list of strings or has the following form:

  <analysisConfigurationFiles>
       <configurationFile>
           <path>path/to/the/file/relative/to/project/base/dir</path>
           <resource>path/to/the/file/in/one/of/the/dependencies</resource>
           <roots>
               <root>configuration/root1</root>
               <root>configuration/root2</root>
               ...
           </roots>
       </configurationFile>
       ...
   </analysisConfigurationFiles>

• path is the path on the filesystem,
• resource is the path to the resource file in one of the artifacts the plugin depends on
• roots is optional and specifies the subtrees of the JSON/XML config that should be used for configuration. If not specified, the whole file is taken into account.

An example of this might be a config file which contains API changes to be ignored in all past versions of a library. The classes to be ignored are specified in a configuration that is specific for each version:

   {
        "0.1.0" : [
            {
                "extension": "revapi.ignore",
                "configuration": [
                    {
                        "code" : "java.method.addedToInterface",
                        "new" : "method void com.example.MyInterface::newMethod()",
                        "justification" : "This interface is not supposed to be implemented by clients."
                    },
                    ...
                ]
            }
        ],
        "0.2.0" : [
            ...
        ]
    }

However, setting this to false might be useful in situations where you have checked your dependencies in another module and don't want do that again. In that case, you might want to configure Revapi to ignore missing classes because it might find the classes from your dependencies as used in your API and would complain that it could not find it. See the docs.

You can modify this set if you use another extensions that change the found differences in a way that the determined new version would not correspond to what it should be.

The default is true, which means that a missing analysis configuration file will fail the build.

If the this property is null, the oldVersion property is checked for a value of the old version of the artifact being built.

The default value is "RELEASE" meaning that the old version is the last released version of the artifact being built.

The individual properties of the dependency (e.g. groupId, artifactId, version, type or classifier) are matched exactly. If you enclose the value in forward slashes, they are matched as regular expressions instead.

E.g. <groupId>com.acme</groupId> will only match dependencies with that exact groupId, while <groupId>/com\.acme(\..*)?/</groupId> will match "com.acme" groupId or any "sub-groupId" thereof (e.g. "com.acme.utils", etc.) using a regular expression.

In rare circumstances this is not a desired behavior though. It is undesired if for example the classes from the provided dependency are used only for establishing desired build order or when they are used in some non-standard scenarios during the build and actually not needed at runtime.

Note that this property only influences the resolution of provided dependencies of the main artifacts, not the transitively reachable provided dependencies. For those, use the resolveTransitiveProvidedDependencies parameter.

Because Maven will report the newest non-snapshot version as the latest release, we might end up comparing a .Beta or other pre-release versions with the new version. This might not be what you want and setting the versionFormat will make sure that a newest version conforming to the version format is used instead of the one resolved by Maven by default.

This parameter is a regular expression pattern that the version string needs to match in order to be considered a RELEASE.