[
https://issues.apache.org/jira/browse/MENFORCER-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385837#comment-17385837
]
Jesse Glick commented on MENFORCER-298:
---------------------------------------
I managed to work around that by patching
https://github.com/jenkinsci/pom/commit/f07a17276ba3d943a2b2550b22231b0163d6a9d1
with
{code:xml}
diff --git pom.xml pom.xml
index 56911f6..0afd265 100644
--- pom.xml
+++ pom.xml
@@ -611,36 +611,6 @@
<requireJavaVersion>
<version>[1.${java.level}.0,]</version>
</requireJavaVersion>
- <requireUpperBoundDeps />
- <enforceBytecodeVersion>
- <maxJdkVersion>1.${java.level}</maxJdkVersion>
- <ignoredScopes>
- <ignoredScope>test</ignoredScope>
- </ignoredScopes>
- <excludes>
- <!-- findbugs dep managed to provided and optional so is
not shipped and missing annotations ok -->
- <exclude>com.google.code.findbugs:annotations</exclude>
- </excludes>
- <!-- To add exclusions in a child POM, use:
- <plugin>
- <artifactId>maven-enforcer-plugin</artifactId>
- <executions>
- <execution>
- <id>display-info</id>
- <configuration>
- <rules>
- <enforceBytecodeVersion>
- <excludes combine.children="append">
- <exclude>…</exclude>
- </excludes>
- </enforceBytecodeVersion>
- </rules>
- </configuration>
- </execution>
- </executions>
- </plugin>
- (or just override java.level) -->
- </enforceBytecodeVersion>
<requireReleaseDeps>
<message>No Snapshots Allowed For Release Versions</message>
<onlyWhenRelease>true</onlyWhenRelease>
{code}
({{requireUpperBoundDeps}} also failed here, for a different reason) and then
using the patched parent
{code:xml}
diff --git pom.xml pom.xml
index cbbdc1e0df..68b6889ce1 100644
--- pom.xml
+++ pom.xml
@@ -28,7 +28,7 @@ THE SOFTWARE.
<parent>
<groupId>org.jenkins-ci</groupId>
<artifactId>jenkins</artifactId>
- <version>1.39</version>
+ <version>1.39-SNAPSHOT</version>
</parent>
<groupId>org.jenkins-ci.main</groupId>
{code}
With that, the build succeeds, and switching back to {{3.0.0-M1}} for Enforcer
causes it to get a compilation error again, all suggesting that MENFORCER-277
indeed worked.
> 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)
