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

SNAPSHOT versions not working in LockFileConverter #901

Open
Andrius-B opened this issue May 16, 2023 · 2 comments · May be fixed by #974
Open

SNAPSHOT versions not working in LockFileConverter #901

Andrius-B opened this issue May 16, 2023 · 2 comments · May be fixed by #974

Comments

@Andrius-B
Copy link

I am trying to use a SNAPSHOT artifact and it seems that these are not supported by the LockFileConverter.java. Simple reproduction is a WORKSPACE file like so:

workspace(name = "rules_jvm_snapshot_repro")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

RULES_JVM_EXTERNAL_TAG = "5.2"

RULES_JVM_EXTERNAL_SHA = "f86fd42a809e1871ca0aabe89db0d440451219c3ce46c58da240c7dcdc00125f"

http_archive(
    name = "rules_jvm_external",
    sha256 = RULES_JVM_EXTERNAL_SHA,
    strip_prefix = "rules_jvm_external-%s" % RULES_JVM_EXTERNAL_TAG,
    url = "https://github.com/bazelbuild/rules_jvm_external/releases/download/%s/rules_jvm_external-%s.tar.gz" % (RULES_JVM_EXTERNAL_TAG, RULES_JVM_EXTERNAL_TAG),
)

load("@rules_jvm_external//:repositories.bzl", "rules_jvm_external_deps")

rules_jvm_external_deps()

load("@rules_jvm_external//:setup.bzl", "rules_jvm_external_setup")

rules_jvm_external_setup()

load("@rules_jvm_external//:defs.bzl", "maven_install")

maven_install(
    artifacts = [
        "com.sample.test:sample:0.0.1-SNAPSHOT",
    ],
    repositories = [
        "<internal repository for development>",
    ],
)

This sample throws an error from

ERROR: An error occurred during the fetch of repository 'maven':
   Traceback (most recent call last):
        File "/private/var/tmp/_bazel_user/ca5242ff51dc74867dfe3863fbdac862/external/rules_jvm_external/coursier.bzl", line 1054, column 13, in _coursier_fetch_impl
                fail("Unable to generate lock file: " + result.stderr)
Error in fail: Unable to generate lock file: 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.
Exception in thread "main" java.lang.IllegalArgumentException: Expected file name (sample-0.0.1-SNAPSHOT) not found in path (v1/<internal>/repository/java/com/sample/test/sample/0.0.1-SNAPSHOT/sample-0.0.1-20230516.072046-1.jar). Current coordinates are com.sample.test:sample:0.0.1-SNAPSHOT
        at com.github.bazelbuild.rules_jvm_external.coursier.LockFileConverter.deriveCoordinateMappings(LockFileConverter.java:266)
        at com.github.bazelbuild.rules_jvm_external.coursier.LockFileConverter.getDependencies(LockFileConverter.java:113)
        at com.github.bazelbuild.rules_jvm_external.coursier.LockFileConverter.main(LockFileConverter.java:78)

The problem is in specifically this part of LockFileConverter.java the script:

      // Now we know the version, we can calculate the expected file name. For now, ignore
      // the fact that there may be a classifier. We're going to derive that if necessary.
      String expectedFileName = coord.getArtifactId() + "-" + version;

      index = pathSubstring.indexOf(expectedFileName);
      if (index == -1) {
        throw new IllegalArgumentException(
            String.format(
                "Expected file name (%s) not found in path (%s). Current coordinates are %s",
                expectedFileName, file, coord));
      }

In the reproduction case I provided the variables when running this part of the script are set to:

pathSubstring="sample-0.0.1-20230516.072046-1.jar"
expectedFileName="sample-0.0.1-SNAPSHOT"

it expects the jar file to be named <mavenName>-<mavenVersion>[-classifier].[extension] but when using SNAPSHOT's the file name actually the actual SNAPSHOT version. I think the parsing should be updated to first strip the artifact name and then go from back to front in the remainder. I can work on a PR if that approach sounds good.

@jmmv
Copy link

jmmv commented Oct 9, 2023

I'm also hitting this and... is there any workaround? I tried replacing the versions in the maven_install rule to be specific and avoid SNAPSHOT... but the downloader still seems confused. This is also with version_conflict_policy="pinned", which says that the rule will preserve the version specified in the rule.

jmmv added a commit to Snowflake-Labs/rules_jvm_external that referenced this issue Oct 10, 2023
Artifacts with snapshots follow a different naming scheme than
non-snapshoted ones.  For snapshotted artifacts, the version component
in the URL is the generic *-SNAPSHOT name, whereas the version component
in the file name is the specific version number.

Fixes bazel-contrib#901.
@jmmv jmmv linked a pull request Oct 10, 2023 that will close this issue
@jmmv
Copy link

jmmv commented Oct 10, 2023

I'm not completely sure if the fix is correct, but I've added something here #974 that seems to do the trick for me.

jmmv added a commit to Snowflake-Labs/rules_jvm_external that referenced this issue Oct 10, 2023
Artifacts with snapshots follow a different naming scheme than
non-snapshoted ones.  For snapshotted artifacts, the version component
in the URL is the generic *-SNAPSHOT name, whereas the version component
in the file name is the specific version number.

Fixes bazel-contrib#901.
jmmv added a commit to Snowflake-Labs/rules_jvm_external that referenced this issue Oct 12, 2023
Artifacts with snapshots follow a different naming scheme than
non-snapshoted ones.  For snapshotted artifacts, the version component
in the URL is the generic *-SNAPSHOT name, whereas the version component
in the file name is the specific version number.

Fixes bazel-contrib#901.
jmmv added a commit to Snowflake-Labs/rules_jvm_external that referenced this issue Oct 12, 2023
Artifacts with snapshots follow a different naming scheme than
non-snapshoted ones.  For snapshotted artifacts, the version component
in the URL is the generic *-SNAPSHOT name, whereas the version component
in the file name is the specific version number.

Fixes bazel-contrib#901.
jmmv added a commit to Snowflake-Labs/rules_jvm_external that referenced this issue Mar 12, 2024
Artifacts with snapshots follow a different naming scheme than
non-snapshoted ones.  For snapshotted artifacts, the version component
in the URL is the generic *-SNAPSHOT name, whereas the version component
in the file name is the specific version number.

Fixes bazel-contrib#901.
sfc-gh-gkolobkov pushed a commit to Snowflake-Labs/rules_jvm_external that referenced this issue Sep 11, 2024
Artifacts with snapshots follow a different naming scheme than
non-snapshoted ones.  For snapshotted artifacts, the version component
in the URL is the generic *-SNAPSHOT name, whereas the version component
in the file name is the specific version number.

Fixes bazel-contrib#901.
sfc-gh-gkolobkov pushed a commit to Snowflake-Labs/rules_jvm_external that referenced this issue Sep 11, 2024
Artifacts with snapshots follow a different naming scheme than
non-snapshoted ones.  For snapshotted artifacts, the version component
in the URL is the generic *-SNAPSHOT name, whereas the version component
in the file name is the specific version number.

Fixes bazel-contrib#901.
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

Successfully merging a pull request may close this issue.

2 participants