[
https://issues.apache.org/jira/browse/MENFORCER-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385831#comment-17385831
]
Jesse Glick commented on MENFORCER-298:
---------------------------------------
My original test case still reproduces the bug in Maven 3.8.1 given
{code:xml}
diff --git pom.xml pom.xml
index cbbdc1e0df..f92cdfe724 100644
--- pom.xml
+++ pom.xml
@@ -112,7 +112,7 @@ THE SOFTWARE.
<repositories>
<repository>
<id>repo.jenkins-ci.org</id>
- <url>http://repo.jenkins-ci.org/public/</url>
+ <url>https://repo.jenkins-ci.org/public/</url>
<!-- allow snapshots -->
</repository>
</repositories>
@@ -120,7 +120,7 @@ THE SOFTWARE.
<pluginRepositories>
<pluginRepository>
<id>repo.jenkins-ci.org</id>
- <url>http://repo.jenkins-ci.org/public/</url>
+ <url>https://repo.jenkins-ci.org/public/</url>
</pluginRepository>
</pluginRepositories>
{code}
I {{install}}’d a snapshot from
https://github.com/apache/maven-enforcer/commit/ab53fd99607eb36554f2fd3af41847ad9568a5ed
and tried
{code:xml}
@@ -575,6 +575,7 @@ THE SOFTWARE.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
+ <version>3.0.0-M4-SNAPSHOT</version>
</plugin>
<!--This plugin's configuration is used to store Eclipse m2e settings
only. It has no influence on the Maven build itself.-->
<plugin>
{code}
but this failed with
{code:none}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M4-SNAPSHOT:enforce
(display-info) on project pom: Unable to parse configuration of mojo
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M4-SNAPSHOT:enforce for
parameter enforceBytecodeVersion: Cannot create instance of class
org.apache.maven.plugins.enforcer.EnforceBytecodeVersion:
org/apache/maven/shared/dependency/tree/DependencyTreeBuilderException:
org.apache.maven.shared.dependency.tree.DependencyTreeBuilderException -> [Help
1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M4-SNAPSHOT:enforce
(display-info) on project pom: Unable to parse configuration of mojo
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M4-SNAPSHOT:enforce for
parameter enforceBytecodeVersion: Cannot create instance of class
org.apache.maven.plugins.enforcer.EnforceBytecodeVersion
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:215)
at …
Caused by: org.apache.maven.plugin.PluginConfigurationException: Unable to
parse configuration of mojo
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M4-SNAPSHOT:enforce for
parameter enforceBytecodeVersion: Cannot create instance of class
org.apache.maven.plugins.enforcer.EnforceBytecodeVersion
at
org.apache.maven.plugin.internal.DefaultMavenPluginManager.populatePluginFields
(DefaultMavenPluginManager.java:665)
at …
Caused by:
org.codehaus.plexus.component.configurator.ComponentConfigurationException:
Cannot create instance of class
org.apache.maven.plugins.enforcer.EnforceBytecodeVersion
at
org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.instantiateObject
(AbstractConfigurationConverter.java:151)
at …
Caused by: java.lang.NoClassDefFoundError:
org/apache/maven/shared/dependency/tree/DependencyTreeBuilderException
at …
at java.lang.Class.newInstance (Class.java:412)
at
org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.instantiateObject
(AbstractConfigurationConverter.java:143)
at …
Caused by: java.lang.ClassNotFoundException:
org.apache.maven.shared.dependency.tree.DependencyTreeBuilderException
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass
(SelfFirstStrategy.java:50)
at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass
(ClassRealm.java:271)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass
(ClassRealm.java:247)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass
(ClassRealm.java:239)
at java.lang.Class.getDeclaredConstructors0 (Native Method)
at …
{code}
> 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)
