[
https://issues.apache.org/jira/browse/MENFORCER-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386720#comment-16386720
]
ASF GitHub Bot commented on MENFORCER-298:
------------------------------------------
jglick opened a new pull request #32: [MENFORCER-298] Ensure bannedDependencies
does not corrupt the classpath when using timestamped snapshots
URL: https://github.com/apache/maven-enforcer/pull/32
See background in
[MENFORCER-298](https://issues.apache.org/jira/browse/MENFORCER-298).
This patch is confirmed to fix the problem on the originally discovered test
case. It does not purport to fix problems when using
```xml
<searchTransitive>false</searchTransitive>
```
nor with other calls to `buildDependencyGraph`, notably from
`banTransitiveDependencies` or `banCircularDependencies` in
`extra-enforcer-rules`. Those _might_ be fixable using
`MavenProject.getDependencyArtifacts` and/or `Artifact.getDependencyTrail`.
I attempted to write an IT to reproduce the bug but failed:
`mrm-maven-plugin` refused to serve the snapshot JAR artifacts needed for my
test even though I tried placing them, along with POMs and
`maven-metadata.xml`, in `maven-enforcer-plugin/src/it/mrm/repository/` using
* a flat directory structure, as in current ITs in this repo
* an unpacked JAR format-2 layout as the [mrm documentation seems to
suggest](http://www.mojohaus.org/mrm/mrm-maven-plugin/examples/invoker-tests.html)
* same, but with prepacked JARs, as `maven-integration-testing` does
I just copied the basic test setup from
`MavenITmng4189UniqueVersionSnapshotTest` with minor modifications. If anyone
is interested I can file a PR showing my attempt.
@stephenc suggested that my simple call to `MavenProject.getArtifacts` might
have some undesirable side effects relating to overeager download of
dependencies. Whatever the case, my patch does not regress any of the existing
unit or integration tests.
@reviewbybees for my colleagues
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> 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, 3.0.0-M1
> Reporter: Jesse Glick
> Priority: Critical
>
> 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
(v7.6.3#76005)
