Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maven plugin spot-bugs leads to mvn incompatibilities in other plugins #21

Closed
blacelle opened this issue Jan 7, 2018 · 4 comments
Closed

Comments

@blacelle
Copy link

blacelle commented Jan 7, 2018

Hello,

According to spot-bugs maven plugin, Spotbugs is compatible with

<prerequisites>
  <maven>3.0.1</maven>
</prerequisites>

However, it seems the use of maven-core in 3.5.2 leads to incompatibilities in other plugins when run in an older maven version (e.g. mvn 3.2.5 and mvn 3.3.9).

In https://github.com/blasd/spotbugs-maven-plugin/tree/IssueMaven3_3, you will find a sample maven project based on mvn-deploy-plugin 2.8.2 which fails during mvn deploy target (in the sample project, mvn deploy will deploy in a local folder). Reming the spotbugs from <plugins> enables deployment.

To reproduce the issue:

  1. clone the fork,
  2. cd exampleProject
  3. run mvn deploy

It shall fail under mvn 3.3 and 3.2, and certainly previous versions (as prerequisites suggests compatibility up to 3.0)

$ mvn --version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
Maven home: C:\Users\blacelle112212\Downloads\apache-maven-3.3.9
Java version: 1.8.0_152, vendor: Oracle Corporation
Java home: C:\HOMEWARE\Install\jdk-8u152-windows-x64\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"

The issue looks like:

[INFO] --- maven-install-plugin:2.4:install (default-install) @ sampleProject ---
ve[WARNING] Error injecting: org.apache.maven.artifact.installer.DefaultArtifactInstaller
com.google.inject.ProvisionException: Unable to provision, see the following errors:

1) Error injecting: private org.eclipse.aether.spi.log.Logger org.apache.maven.repository.internal.DefaultVersionRangeResolver.logger
  while locating org.apache.maven.repository.internal.DefaultVersionRangeResolver
  while locating java.lang.Object annotated with *
  at org.eclipse.sisu.wire.LocatorWiring
  while locating org.eclipse.aether.impl.VersionRangeResolver
    for parameter 2 at org.eclipse.aether.internal.impl.DefaultDependencyCollector.<init>(Unknown Source)
  while locating org.eclipse.aether.internal.impl.DefaultDependencyCollector
  while locating java.lang.Object annotated with *
  at org.eclipse.sisu.wire.LocatorWiring
  while locating org.eclipse.aether.impl.DependencyCollector
    for parameter 5 at org.eclipse.aether.internal.impl.DefaultRepositorySystem.<init>(Unknown Source)
  while locating org.eclipse.aether.internal.impl.DefaultRepositorySystem
  while locating java.lang.Object annotated with *
  while locating org.apache.maven.artifact.installer.DefaultArtifactInstaller
Caused by: java.lang.IllegalArgumentException: Can not set org.eclipse.aether.spi.log.Logger field org.apache.maven.repository.internal.DefaultVersionRangeResolver.logger to org.eclipse.aether.internal.impl.slf4j.Slf4jLoggerFactory
        at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:167)
        at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:171)
        at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:81)
        at java.lang.reflect.Field.set(Field.java:764)
        at org.eclipse.sisu.bean.BeanPropertyField.set(BeanPropertyField.java:72)
        at org.eclipse.sisu.plexus.ProvidedPropertyBinding.injectProperty(ProvidedPropertyBinding.java:48)
        at org.eclipse.sisu.bean.BeanInjector.injectMembers(BeanInjector.java:52)
        at com.google.inject.internal.MembersInjectorImpl.injectMembers(MembersInjectorImpl.java:140)
        at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:114)
        at com.google.inject.internal.ConstructorInjector.access$000(ConstructorInjector.java:32)
        at com.google.inject.internal.ConstructorInjector$1.call(ConstructorInjector.java:89)
        at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
        at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:133)
        at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
        at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:87)
        at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:267)
        at com.google.inject.internal.FactoryProxy.get(FactoryProxy.java:56)
        at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
        at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
        at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
        at org.eclipse.sisu.inject.Guice4$1.get(Guice4.java:162)

Given the stack, it appears the issue may also appear in the install plugin (maven-install-plugin:2.4), in my original project, the issue is with mvn deploy plugin 2.8.2

@hazendaz
Copy link
Member

hazendaz commented Jan 7, 2018 via email

@blacelle
Copy link
Author

blacelle commented Jan 7, 2018

I initially get an issue with maven-deploy-plugin in its latest versiob (2.8.2). https://github.com/apache/maven-plugins/blob/c719f8da6d9380d2b9f3f0b311b1b2cbcb3f9cf7/maven-deploy-plugin/pom.xml shows it might be a best practise to align maven dependencies

<dependency>
  <groupId>org.apache.maven</groupId>
  <artifactId>maven-project</artifactId>
  <version>${mavenVersion}</version>
</dependency>

with prerequisites

<prerequisites>
  <maven>${mavenVersion}</maven>
</prerequisites>

I suppose spotbugs-maven-plugin should also follow this pattern.

The first concern raised with this ticket is the reproducibility of some of my builds (which relies on spotbugs) as it appeared OK in local (mvn 3.5.2) but KO in some of my customers Jenkins instances (which may lock mvn down to 3.2.5 3.3.9). Increasing the prerequisites to 3.5.2 would have been fine as it have been clearer what was the issue. About spotbugs-maven-plugin not being compatible with mvn 3.2.X and 3.3.X, I'm OK with this. In my own cases, I'm ready to introduce profiles in order to fully exclude spotbugs-maven-plugin in the environments where mvn 3.5 is not available.

Seems like some potential leaks in classloaders

It might be the root-cause. I recently encountered the same stacks (Error injecting: private org.eclipse.aether.spi.log.Logger org.apache.maven.repository.internal.DefaultVersionRangeResolver.logger) but on another project NOT relying on spotbugs. The errors appears on mvn install when inside a sub-module, while mvn install on the root module is OK which seems weird as mvn install in the root-module will also process the sub-module

effweh-ait added a commit to effweh-ait/archistar-smc that referenced this issue Feb 7, 2018
@hazendaz
Copy link
Member

@BlasD I'm submitting a commit now that should provide backwards support. I'm trying not to enforce 3.5.2. I think generally that would not have been an issue had it not been for underlying injection changes which seem to conflict badly. Would it be possible for you to give the latest snapshot a try once that lands? It should be on there in next hour or so.

@hazendaz
Copy link
Member

Version 3.1.2 released fixing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants