[MENFORCER-298] bannedDependencies can break compilation against a timestamped snapshot

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Done
• Affects Version/s: 3.0.0-M1, 3.0.0-M3
• Component/s: Standard Rules
• Flags: Patch
• Assignee: Robert Scholte
• Reporter: Jesse Glick
• Created: 05/Mar/18 20:19
• Updated: 23/Jul/21 08:51
• Resolved: 22/Jul/21 12:17

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 stephenc who reviewed this strange misbehavior with me.

Issue Links

• relates to: MENFORCER-168 In a multi module project "bannedDependencies" rule tries to resolve project artifacts from external repository
• relates to: MNG-4189 Maven not picking up specific timestamped version dependency when a later timestamped version was downloaded and already present in the local repository
• relates to: MENFORCER-277 Upgrade maven-dependency-tree to 3.x
• links to: CloudBees-internal issue
• links to: GitHub Pull Request #32
• links to: PR 32