big-solutions/boot-mvn

Exception when using mvn task

dball opened this issue · 5 comments

dball commented

Hi, I thought I'd try out this plugin in order to generate the maven dependency document. Unfortunately, I wind up with an exception:

  clojure.lang.ExceptionInfo: tried to access method com.google.common.collect.MapMaker.makeComputingMap(Lcom/google/common/base/Function;)Ljava/util/concurrent/ConcurrentMap; from class com.google.inject.internal.Annotations$AnnotationChecker
    data: {:file
           "/var/folders/q8/q9m6fhqx7jz9r9wz72dsvsxh0000gn/T/boot.user4106392536589086707.clj",
           :line 33}
java.lang.IllegalAccessError: tried to access method com.google.common.collect.MapMaker.makeComputingMap(Lcom/google/common/base/Function;)Ljava/util/concurrent/ConcurrentMap; from class com.google.inject.internal.Annotations$AnnotationChecker
com.google.inject.internal.Annotations$AnnotationChecker.<init>                  Annotations.java:  104
                com.google.inject.internal.Annotations.<clinit>                  Annotations.java:  122
                  com.google.inject.Key.ensureRetainedAtRuntime                          Key.java:  362
                              com.google.inject.Key.strategyFor                          Key.java:  354
                                      com.google.inject.Key.get                          Key.java:  222
                   org.eclipse.sisu.wire.ParameterKeys.<clinit>                ParameterKeys.java:   28
                org.eclipse.sisu.wire.DependencyAnalyzer.<init>           DependencyAnalyzer.java:   92
                   org.eclipse.sisu.wire.ElementAnalyzer.<init>              ElementAnalyzer.java:   87
                     org.eclipse.sisu.wire.WireModule.configure                   WireModule.java:   74
         com.google.inject.spi.Elements$RecordingBinder.install                     Elements.java:  229
                     com.google.inject.spi.Elements.getElements                     Elements.java:  103
         com.google.inject.internal.InjectorShell$Builder.build                InjectorShell.java:  136
       com.google.inject.internal.InternalInjectorCreator.build      InternalInjectorCreator.java:  104
                         com.google.inject.Guice.createInjector                        Guice.java:   94
                         com.google.inject.Guice.createInjector                        Guice.java:   71
                         com.google.inject.Guice.createInjector                        Guice.java:   61
   org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector       DefaultPlexusContainer.java:  477
              org.codehaus.plexus.DefaultPlexusContainer.<init>       DefaultPlexusContainer.java:  203
                        org.apache.maven.cli.MavenCli.container                     MavenCli.java:  401
                           org.apache.maven.cli.MavenCli.doMain                     MavenCli.java:  208
                           org.apache.maven.cli.MavenCli.doMain                     MavenCli.java:  188

Which suggests perhaps an undeclared dependency?

Hi Donald,

Thanks for the letting us know! It definitely looks like a dependency versioning issue.

Could you please include the command you ran as well as boot version so that I can try and reproduce the issue?

dball commented

Right on! My task is essentially:

(deftask build-docs
  []
  (comp (pom :project 'sparkfund/my-project
             :version version)
        (mvn :args "project-info-reports:dependencies")))

My boot version:

#http://boot-clj.com
#Tue Dec 20 10:24:25 EST 2016
BOOT_CLOJURE_NAME=org.clojure/clojure
BOOT_CLOJURE_VERSION=1.9.0-alpha14
BOOT_VERSION=2.6.0

I couldn't reproduce it, but I did find an issue with plugin dependencies isolation that could have caused this problem. The fix is in the latest version "0.1.5" .

Please let me know if it works now.

dball commented

Hey, nice, that fixes that problem.

One interesting wrinkle: when I add the (target) task to the composed task fn, I wind up with my reports written to target/target/site/dependencies.html. I wouldn't have expected the target directory to be doubled as it is. No big deal, I can debug if it becomes irritating, just thought I'd mention it.

Cheers!

Glad to hear it works!

Actually, the bit about double target was intentional.Typically, maven produces a whole lot of stuff in its target, so you are very likely to need to sift between mvn and target tasks anyway (e.g. sift to move site one directory up and include just that). That is just slightly easier if all maven outputs are grouped in its own directory rather than spilled in the main one. The drawback is that the default behavior is not intuitive, as you mentioned.

I'm going to think about it, but in any case this is going to the faq. Cheers!