[maven-plugin] Provided dependencies cannot be loaded

[zentol]

When a module being verified has a provided dependency on some other module that is required at compile time, then japicmp cannot load the classes from the first module because the provided dependency is not put on the classpath.

Steps to reproduce:

• create a multi-module project with 2 modules
• Module 1 contains some Interface
• Module 2 contains a class implementing that interface
• Module 2 has a provided dependency on Module 1
• add this japicmp configuration to Module 2:

  <plugin>
  <groupId>com.github.siom79.japicmp</groupId>
  <artifactId>japicmp-maven-plugin</artifactId>
  <version>0.15.6</version>
  <executions>
      <execution>
          <phase>verify</phase>
          <goals>
              <goal>cmp</goal>
          </goals>
      </execution>
  </executions>
  <configuration>
      <oldVersion>
          <dependency>
              <groupId>${project.groupId}</groupId>
              <artifactId>${project.artifactId}</artifactId>
              <version>1.0</version>
              <type>${project.packaging}</type>
          </dependency>
      </oldVersion>
  </configuration>
  </plugin>

• run mvn verify

I can provide such a project as a zip if desired.

This happens because to generate the classpath The JapiCmpMojo is determining the set of dependencies via RepositorySystem#resolveDependencies in setUpClassPathUsingMavenProject(). However this does not give you all dependencies that the module needs to compile, but only those dependencies that another module depending on that module would need, and since provided (and optional) dependencies are not transitive they are not put on the classpath.

I couldn't find a nice way to solve this via the RepositorySystem API; the only alternative I could come up with is to use a custom DependencySelector that properly selects all dependencies that are required at compile time.

This selector would be used like this:

final DefaultRepositorySystemSession repositorySystemSession =
                new DefaultRepositorySystemSession(mavenParameters.getRepoSession());
            repositorySystemSession.setDependencySelector(new CompileScopeDependencySelector());

            DependencyResult dependencyResult = mavenParameters.getRepoSystem().resolveDependencies(
                repositorySystemSession,
                new DependencyRequest(
                    request, (node, parents) -> true));

I'm still prototyping such a selector, but it should be something along the lines of:

class CompileScopeDependencySelector implements DependencySelector {

  private final boolean isTopLevel;

  CompileScopeDependencySelector() {
        this(true);
  }

  private CompileScopeDependencySelector(boolean isTopLevel) {
        this.isTopLevel = isTopLevel;
  }

  @Override
  public boolean selectDependency(Dependency dependency) {
        return isNoTestDependency(dependency);
  }

  @Override
  public DependencySelector deriveChildSelector(DependencyCollectionContext context) {
        return isTopLevel
            ? new CompileScopeDependencySelector(false)
            : new CompileScopeTransitiveDependencySelector();
  }

  private static class CompileScopeTransitiveDependencySelector implements DependencySelector {

        @Override
        public boolean selectDependency(Dependency dependency) {
          return isNoTestDependency(dependency) && !isProvidedDependency(dependency) && !dependency.isOptional();
        }

        @Override
        public DependencySelector deriveChildSelector(DependencyCollectionContext context) {
          return this;
        }
  }

  private static boolean isNoTestDependency(Dependency dependency) {
        return !"test".equalsIgnoreCase(dependency.getScope());
  }

  private static boolean isProvidedDependency(Dependency dependency) {
        return "provided".equalsIgnoreCase(dependency.getScope());
  }
}

Alternatively, it might be possible to get the original set of dependencies from the Maven model, and create a CollectRequest for those dependencies instead (i.e., pretend to be the module).

[cstamas]

Somewhat related to https://github.com/siom79/japicmp/issues/327

[zentol]

No longer occurs with 1.16.0; considering it fixed.