Pushing an artifact on 2.8.3 fails with java.lang.NoSuchMethodError: org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.getBufferCapacityForTransfer(J)I about boot HOT 10 OPEN

I'd guess this was caused by upgrading org.apache.maven.wagon/wagon-http: 55e4b55#diff-9db74cbad6290729409297ab0f2a33a6R21

I don't see why Pomegranate wouldn't work with the latest Wagon-http but that does seem like the obvious reason. I think Pomegranate also already has a dependency on wagon-http so maybe boot doesn't even need the direct dependency.

from boot.

@ska2342 The original authors certainly have no capacity to maintain this project anymore. Unless you are really stuck with Boot (like me), I suggest moving on to either Leiningen or tools.deps.

To work around this particular issue, I rolled back to 2.8.2.

from boot.

I see this too.

from boot.

Facing the same problem. I upgraded from 2.8.0 to 2.8.3 to get the newer nrepl versions which seem to be required by Cider. Any help highly appreciated.

from boot.

@ska2342 CIDER works fine with Boot 2.8.2, it should inject the correct nREPL version upon cider-jack-in automatically.

from boot.

@alexander-yakushev, I start the REPL via a boot task from the command-line and inject the nREPL from there. Anyhow, I just use 2.8.3 in development and don't commit my local change until this issue is fixed. Thanks for the hint, though.

from boot.

@ska2342 In that case, you can also use a Boot task like this to set the nREPL version manually:

(deftask cider "" []
  (reset! boot.repl/*default-dependencies*
          '[[nrepl "0.6.0"]
            [cider/cider-nrepl "0.22.0-SNAPSHOT"]
            [refactor-nrepl "2.4.0"]])
  (reset! boot.repl/*default-middleware*
          ['cider.nrepl/cider-middleware
           'refactor-nrepl.middleware/wrap-refactor])
  identity)

Then you boot cider repl to start the REPL.

from boot.

I just upgraded a project from 2.7.2, and I think I ran into this same issue.

My stack trace:

java.lang.Thread.run Thread.java: 748 java.util.concurrent.ThreadPoolExecutor$Worker.run ThreadPoolExecutor.java: 624 java.util.concurrent.ThreadPoolExecutor.runWorker ThreadPoolExecutor.java: 1149 java.util.concurrent.FutureTask.run FutureTask.java: 266 ... clojure.core/binding-conveyor-fn/fn core.clj: 2022 boot.core/boot/fn core.clj: 1031 boot.core/run-tasks core.clj: 1022 boot.task.built-in/eval2671/fn/fn/fn built_in.clj: 576 boot.task.built-in/eval3044/fn/fn/fn built_in.clj: 875 boot.task.built-in/eval3182/fn/fn/fn built_in.clj: 978 adzerk.bootlaces/eval3576/fn/fn/fn bootlaces.clj: 65 adzerk.bootlaces/eval3532/fn/fn/fn bootlaces.clj: 54 boot.task.built-in/eval3232/fn/fn/fn built_in.clj: 1077 boot.pod/call-in* pod.clj: 413 ... org.projectodd.shimdandy.impl.ClojureRuntimeShimImpl.invoke ClojureRuntimeShimImpl.java: 97 org.projectodd.shimdandy.impl.ClojureRuntimeShimImpl.invoke ClojureRuntimeShimImpl.java: 104 ... boot.pod/call-in* pod.clj: 410 boot.pod/eval-fn-call pod.clj: 359 clojure.core/apply core.clj: 657 ... boot.aether/deploy aether.clj: 352 ... cemerick.pomegranate.aether/deploy aether.clj: 391 cemerick.pomegranate.aether/deploy aether.clj: 427 clojure.core/apply core.clj: 657 ... cemerick.pomegranate.aether/deploy-artifacts aether.clj: 308 cemerick.pomegranate.aether/deploy-artifacts aether.clj: 358 ... org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy DefaultRepositorySystem.java: 384 org.eclipse.aether.internal.impl.DefaultDeployer.deploy DefaultDeployer.java: 223 org.eclipse.aether.internal.impl.DefaultDeployer.deploy DefaultDeployer.java: 289 org.eclipse.aether.connector.basic.BasicRepositoryConnector.put BasicRepositoryConnector.java: 283 org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run BasicRepositoryConnector.java: 359 org.eclipse.aether.connector.basic.BasicRepositoryConnector$PutTaskRunner.runTask BasicRepositoryConnector.java: 519 org.eclipse.aether.transport.wagon.WagonTransporter.put WagonTransporter.java: 419 org.eclipse.aether.transport.wagon.WagonTransporter.execute WagonTransporter.java: 436 org.eclipse.aether.transport.wagon.WagonTransporter$PutTaskRunner.run WagonTransporter.java: 653 org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put AbstractHttpClientWagon.java: 626 org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put AbstractHttpClientWagon.java: 646 org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put AbstractHttpClientWagon.java: 652 org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put AbstractHttpClientWagon.java: 670 org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put AbstractHttpClientWagon.java: 713 org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.execute AbstractHttpClientWagon.java: 958 org.apache.http.impl.client.CloseableHttpClient.execute CloseableHttpClient.java: 83 org.apache.http.impl.client.InternalHttpClient.doExecute InternalHttpClient.java: 185 org.apache.http.impl.execchain.RedirectExec.execute RedirectExec.java: 111 org.apache.http.impl.execchain.RetryExec.execute RetryExec.java: 89 org.apache.http.impl.execchain.ProtocolExec.execute ProtocolExec.java: 185 org.apache.http.impl.execchain.MainClientExec.execute MainClientExec.java: 272 org.apache.http.protocol.HttpRequestExecutor.execute HttpRequestExecutor.java: 123 org.apache.http.protocol.HttpRequestExecutor.doSendRequest HttpRequestExecutor.java: 238 org.apache.http.impl.conn.CPoolProxy.sendRequestEntity CPoolProxy.java: 160 org.apache.http.impl.DefaultBHttpClientConnection.sendRequestEntity DefaultBHttpClientConnection.java: 156 org.apache.maven.wagon.shared.http.AbstractHttpClientWagon$RequestEntityImplementation.writeTo AbstractHttpClientWagon.java: 185 org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.access$000 AbstractHttpClientWagon.java: 112 java.lang.NoSuchMethodError: org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.getBufferCapacityForTransfer(J)I clojure.lang.ExceptionInfo: org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.getBufferCapacityForTransfer(J)I line: 193
I can verify that rolling back to boot 2.8.2 worked around the deployment problem (yay, thank you!).

I don't think it matters, but just in case: This was on ubuntu 16.04.6, OpenJDK 1.8.0_212, using clojure 1.9.0.

from boot.

Is anyone still working on boot? There's no real movement in the project, even with serious bugs like this around. Don't want to be pushy. It's totally fine if the maintainers have more important stuff to work on. I'd just like to know.

from boot.

The workaround is fine for me. Been on 2.8.2 for builds and 2.8.3 for local development (nrepl requirement) for ages. I did some heavy investments in my build tooling with boot. Might also consider moving to clojurephant for the more dynamic parts of the build script. Yuck, syntax. ;-)

from boot.