Uploaded image for project: 'Maven Enforcer Plugin'
  1. Maven Enforcer Plugin
  2. MENFORCER-298

bannedDependencies can break compilation against a timestamped snapshot

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 3.0.0-M1, 3.0.0-M3
    • Fix Version/s: None
    • Component/s: Standard Rules
    • Labels:
      None
    • Flags:
      Patch

      Description

      While working heavily with timestamped snapshots across repositories (reactors) I found occasional build errors suggesting that maven-compiler-plugin was picking up the wrong version of a dependency. To reproduce, using say Maven 3.5.2:

      git clone https://github.com/jenkinsci/jenkins
      cd jenkins
      git checkout e2c1ae15a3bc6a9e1dcde0bc139b34d2c5812214
      mvn -DskipTests -am -pl core clean install
      

      Compilation will fail with some errors like

      [ERROR] .../jenkins/core/src/main/java/jenkins/security/ClassFilterImpl.java:[77,19] error: cannot find symbol
      [ERROR]   symbol:   method setDefault(ClassFilterImpl)
      [ERROR]   location: class ClassFilter
      

      What is going on here is that the artifact repository contains various timestamped snapshots for this base version of remoting. The jenkins commit requests the -3 snapshot in its pom.xml; the newest currently available is -10, which represents an unrelated branch. The compiler error happens when jenkins/core/src/main/java/ is compiled against the -10 artifact.

      Now MavenITmng4189UniqueVersionSnapshotTest in maven-integration-testing verifies that the compiler classpath in such cases is correct, and in fact you can patch the IT to actually run the compiler and it will work as expected: Maven will copy the requested timestamped snapshot artifacts to the corresponding base versions, then return those from MavenProject.getCompileClasspathElements, as this blog says it will (without further explanation). Yet it breaks in jenkins.

      I managed to narrow this down to the fact that jenkins used the bannedDependencies Enforcer rule. If it uses only, say, <alwaysPass/>, then there is no error. But running bannedDependencies changes the behavior of compilation (even though the enforce mojo passes): the -10 artifacts (pom and jar) are downloaded, and the base artifacts (esp. remoting-3.15-SNAPSHOT.jar) are overwritten with the -10 versions, not the -3 versions as expected. By patching BannedDependencies I found that this problem occurs iff buildDependencyGraph is called. By adding

      System.setSecurityManager( new SecurityManager()
      {
          @Override
          public void checkWrite( String file )
          {
              if ( file.contains( "remoting" ) )
              {
                  System.err.println( file );
                  Thread.dumpStack();
              }
          }
          @Override
          public void checkPermission( Permission perm )
          {
          }
      }
      );
      

      I found this stack trace:

      at java.io.FileOutputStream.<init>(FileOutputStream.java:200)
      at java.io.FileOutputStream.<init>(FileOutputStream.java:162)
      at org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:166)
      at org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:150)
      at org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:464)
      at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:329)
      at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:224)
      at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:338)
      at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:202)
      at org.apache.maven.shared.dependency.graph.internal.Maven31DependencyGraphBuilder.resolveDependencies(Maven31DependencyGraphBuilder.java:127)
      at org.apache.maven.shared.dependency.graph.internal.Maven31DependencyGraphBuilder.buildDependencyGraph(Maven31DependencyGraphBuilder.java:113)
      at org.apache.maven.shared.dependency.graph.internal.DefaultDependencyGraphBuilder.buildDependencyGraph(DefaultDependencyGraphBuilder.java:91)
      at org.apache.maven.shared.dependency.graph.internal.DefaultDependencyGraphBuilder.buildDependencyGraph(DefaultDependencyGraphBuilder.java:66)
      

      And passing -Daether.artifactResolver.snapshotNormalization=false resolves the issue.

      CC Stephen Connolly who reviewed this strange misbehavior with me.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                jglick@netbeans.org Jesse Glick
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated: