[jira] [Closed] (MENFORCER-298) bannedDependencies can break compilation against a timestamped snapshot

["Robert Scholte (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/MENFORCER-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Scholte closed MENFORCER-298.
------------------------------------
      Assignee: Robert Scholte
    Resolution: Done

MENFORCER-277 has been fixed, and based on the comments I will assume that it will fix this issue too. Otherwise we can reopen it and try to write an integrationtest to reproduce the issue.

> bannedDependencies can break compilation against a timestamped snapshot
> -----------------------------------------------------------------------
>
>                 Key: MENFORCER-298
>                 URL: https://issues.apache.org/jira/browse/MENFORCER-298
>             Project: Maven Enforcer Plugin
>          Issue Type: Bug
>          Components: Standard Rules
>    Affects Versions: 3.0.0-M1, 3.0.0-M3
>            Reporter: Jesse Glick
>            Assignee: Robert Scholte
>            Priority: Major
>
> 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:
> {code:none}
> git clone https://github.com/jenkinsci/jenkins
> cd jenkins
> git checkout e2c1ae15a3bc6a9e1dcde0bc139b34d2c5812214
> mvn -DskipTests -am -pl core clean install
> {code}
> Compilation will fail with some errors like
> {code:none}
> [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
> {code}
> What is going on here is that [the artifact repository|http://repo.jenkins-ci.org/public/org/jenkins-ci/main/remoting/3.15-SNAPSHOT/] 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|http://blog.sonatype.com/2009/12/maven-dependency-resolution-a-repository-perspective/] 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
> {code}
> 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 )
>     {
>     }
> }
> );
> {code}
> I found this stack trace:
> {code:none}
> 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)
> {code}
> And passing {{-Daether.artifactResolver.snapshotNormalization=false}} resolves the issue.
> CC [~stephenc] who reviewed this strange misbehavior with me.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)