You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is related to #1307, which I filed a month ago and then (myself) closed, but now better understand:
Something is very wrong either somewhere in rules_jvm_external itself (more likely), or perhaps even in https://get-coursier.io (less likely):
I have had several cases of massive confusion on my part which all boil down to some code somewhere in this project apparently assuming that Maven Version strings (1.2.3) must start with a digit? That is NOT necessarily so in Maven! Based on my discussion with @cstamas (a Maven maintainer), this is the "spec" (and it does NOT say "has to start with digit), and from here, quote:
A: So "v1.3.4" is completely okay version as Maven goes.
B: Maven does not lay down "compliant version", ultimately, it will handle it as opaque string (ordered by natural order).
But this is not what rules_jvm_external (at least its latest released version 6.6) does.
Following are 2 completely separate use cases illustrating specific issues, both apparently due to the same root cause:
vX.Y.Z instead X.Y.Z
This is the (long, sorry) story of how rules_jvm_external massively fucks up com.github.multiformats:java-multihash:v1.3.4 and somehow confused Maven <version> with <type> - apparently due to its version starting with a v prefix. That artefact is not deployed to Maven central, but in theory it could be. I believe it would work just fine e.g. a local mvn install, and depending on it from Gradle. It's rules_jvm_external which handles Maven versions differently than other tools in the broader Maven ecosystem.
You cannot however not depend e.g. on https://jitpack.io/#vorburger/java-multihash/ed14893c86 with com.github.vorburger:java-multihash:ed14893c86. The difference being only that it's a Git SHA which just so happens to start with a letter instead of a digit! Try adding that here, and note how pinning fails:
$ REPIN=1 bazel run @enola_maven//:pin
DEBUG: /home/vorburger/.cache/bazel/_bazel_vorburger/a3cf8df34f0c7a76e9926daaad9ffbf4/external/rules_jvm_external+/private/rules/coursier.bzl:411:10: The inputs to enola_maven_install.json have changed, but the lock file has not been regenerated. Consider running 'bazel run @enola_maven//:pin'
INFO: Repository rules_jvm_external++maven+unpinned_enola_maven instantiated at:
<builtin>: in <toplevel>
Repository rule coursier_fetch defined at:
/home/vorburger/.cache/bazel/_bazel_vorburger/a3cf8df34f0c7a76e9926daaad9ffbf4/external/rules_jvm_external+/private/rules/coursier.bzl:1434:33: in <toplevel>
INFO: repository @@rules_jvm_external++maven+unpinned_enola_maven' used the following cache hits instead of downloading the corresponding file.
* Hash '2b78bfdd3ef13fd1f42f158de0f029d7cbb1f4f652d51773445cf2b6f7918a87' for https://github.com/coursier/coursier/releases/download/v2.1.8/coursier.jar
If the definition of 'repository @@rules_jvm_external++maven+unpinned_enola_maven' was updated, verify that the hashes were also updated.
ERROR: /home/vorburger/.cache/bazel/_bazel_vorburger/a3cf8df34f0c7a76e9926daaad9ffbf4/external/rules_jvm_external+/private/rules/coursier.bzl:928:13: An error occurred during the fetch of repository 'rules_jvm_external++maven+unpinned_enola_maven':
Traceback (most recent call last):
File "/home/vorburger/.cache/bazel/_bazel_vorburger/a3cf8df34f0c7a76e9926daaad9ffbf4/external/rules_jvm_external+/private/rules/coursier.bzl", line 1039, column 38, in _coursier_fetch_impl
dep_tree = make_coursier_dep_tree(
File "/home/vorburger/.cache/bazel/_bazel_vorburger/a3cf8df34f0c7a76e9926daaad9ffbf4/external/rules_jvm_external+/private/rules/coursier.bzl", line 928, column 13, in make_coursier_dep_tree
fail("Error while fetching artifact with coursier: " + exec_result.stderr)
Error in fail: Error while fetching artifact with coursier: OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release.
Resolution error: Error downloading com.github.vorburger:java-multihash:
not found: https://repo.maven.apache.org/maven2/com/github/vorburger/java-multihash//java-multihash-.pom
not found: https://jitpack.io/com/github/vorburger/java-multihash//java-multihash-.pom
ERROR: no such package '@@rules_jvm_external++maven+unpinned_enola_maven//': Error while fetching artifact with coursier: OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release.
Resolution error: Error downloading com.github.vorburger:java-multihash:
not found: https://repo.maven.apache.org/maven2/com/github/vorburger/java-multihash//java-multihash-.pom
not found: https://jitpack.io/com/github/vorburger/java-multihash//java-multihash-.pom
ERROR: /home/vorburger/.cache/bazel/_bazel_vorburger/a3cf8df34f0c7a76e9926daaad9ffbf4/external/rules_jvm_external++maven+enola_maven/BUILD:7479:6: @@rules_jvm_external++maven+enola_maven//:pin depends on @@rules_jvm_external++maven+unpinned_enola_maven//:pin in repository @@rules_jvm_external++maven+unpinned_enola_maven which failed to fetch. no such package '@@rules_jvm_external++maven+unpinned_enola_maven//': Error while fetching artifact with coursier: OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release.
Resolution error: Error downloading com.github.vorburger:java-multihash:
not found: https://repo.maven.apache.org/maven2/com/github/vorburger/java-multihash//java-multihash-.pom
not found: https://jitpack.io/com/github/vorburger/java-multihash//java-multihash-.pom
ERROR: Analysis of target '@@rules_jvm_external++maven+enola_maven//:pin' failed; build aborted: Analysis failed
INFO: Elapsed time: 5.350s, Critical Path: 0.00s
INFO: 1 process: 1 internal.
ERROR: Build did NOT complete successfully
ERROR: Build failed. Not running target
Look closely at the error, and notice that the version (which should be ed14893c86) was ignored and got lost!
Obviously it's not finding e.g. java-multihash-.pom - because it should really be looking for java-multihash-ed14893c86.pom.
The text was updated successfully, but these errors were encountered:
This issue is related to #1307, which I filed a month ago and then (myself) closed, but now better understand:
Something is very wrong either somewhere in
rules_jvm_external
itself (more likely), or perhaps even in https://get-coursier.io (less likely):I have had several cases of massive confusion on my part which all boil down to some code somewhere in this project apparently assuming that Maven Version strings (
1.2.3
) must start with a digit? That is NOT necessarily so in Maven! Based on my discussion with @cstamas (a Maven maintainer), this is the "spec" (and it does NOT say "has to start with digit), and from here, quote:But this is not what
rules_jvm_external
(at least its latest released version 6.6) does.Following are 2 completely separate use cases illustrating specific issues, both apparently due to the same root cause:
vX.Y.Z instead X.Y.Z
This is the (long, sorry) story of how
rules_jvm_external
massively fucks upcom.github.multiformats:java-multihash:v1.3.4
and somehow confused Maven<version>
with<type>
- apparently due to its version starting with av
prefix. That artefact is not deployed to Maven central, but in theory it could be. I believe it would work just fine e.g. a localmvn install
, and depending on it from Gradle. It'srules_jvm_external
which handles Maven versions differently than other tools in the broader Maven ecosystem.JitPack.io uses Git SHA as version!
You can depend e.g. on https://jitpack.io/#vorburger/java-multibase/166578b51d with
com.github.vorburger:java-multibase:166578b51d
inartifacts
, usinghttps://jitpack.io
inrepositories
- works perfectly.You cannot however not depend e.g. on https://jitpack.io/#vorburger/java-multihash/ed14893c86 with
com.github.vorburger:java-multihash:ed14893c86
. The difference being only that it's a Git SHA which just so happens to start with a letter instead of a digit! Try adding that here, and note how pinning fails:Look closely at the error, and notice that the version (which should be
ed14893c86
) was ignored and got lost!Obviously it's not finding e.g.
java-multihash-.pom
- because it should really be looking forjava-multihash-ed14893c86.pom
.The text was updated successfully, but these errors were encountered: