In the function, if there are three parts to the coordinates, we treat the third part as a version number unless there's an @ sign in the coordinates. You should only be running into this if there's a coordinate which specifies a classifier or extension.

Presumably to recreate the issue it's enough to have one of these dependencies in the artifacts of a maven_install or install tag?

The function mentions that version numbers are optional. This is the case where someone has specified a BOM, and then wants to specify the extension to use for an entry in the artifacts list of a maven_install. At that point, it becomes essentially impossible to determine which of the two coordinate variants we want to use, and we need to guess.

Without a SemVer 1.0.0 compliant version number, Maven can't do version ordering, which suggests that people should be using that, but I don't think it's the place for rules_jvm_external to be telling people that.

Don't see mentions of version being optional around Maven BOM docs https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms
Logically BOM should be very specific so rules_jvm_external should probably prefer g:a:v over g:a:p (in case g:a:p is even actually possible to hit somewhere in the wild)

Version numbers are optional in artifacts listed in BOMs, even with Maven. You'd end up with something like:

<dependencies>
  <dependency>
    <groupId>com.example</groupId>
    <artifactId>foo</artifactId</artifactId>
  </dependency>
</dependencies>

Do I understand correctly:

We are trying to support BOM's and given that a BOM specifies the library versions for those that inherit it, it should not be necessary to specify the version in the maven.install() coordinates, correct? i.e. group:artifact should be enough?

Do I understand that the issue we're running into is:

User has provided group:artifact:package in the context of a BOM and it's impossible to tell this apart from group:artifact:version when version is non-semver?

I would argue the rareness of 2-arity + package means that if you see '3' co-ordinates it should be assumed to be g:a:v, and if somebody wants to specify a package while omitting the version, then they just cannot expect to reassign meaning to the v token

Instead from a design point of view you would expect to either:

• use g:a:v:p (which defeats the purpose of the bom)
• or g:a::p if you must not specify the version (empty version)
• or for readability, if there were a reserved character which cannot be a version by itself e.g. g:a:?:p or g:a:_:p or g:a:*:p
• or one that actually works today, use the full expanded format below

maven.artifact(
            group = "com.google.guava",
            artifact = "guava",
            packaging = "jar",
        )

The key with these examples is that it ensure that each index of each element always retaining the same meaning regardless of context or value.

my two cents...

We are trying to support BOM's and given that a BOM specifies the library versions for those that inherit it, it should not be necessary to specify the version in the maven.install() coordinates, correct? i.e. group:artifact should be enough?

Correct

User has provided group:artifact:package in the context of a BOM and it's impossible to tell this apart from group:artifact:version when version is non-semver?

Essentially, this is what I'm saying. Using g:a::p is probably the best solution. I'll put a PR together to support this.

Apologies. The format for the existing style is group:artifact[:packaging[:classifier]]:version, so g:a:p: is the correct form, and that is already supported.

There seems to be a mix of string formats

• g:a:[p:[c:]]v https://github.com/bazel-contrib/rules_jvm_external/blob/6.5/specs.bzl#L129
• g:a:[t:[s:]]v and g:a[:v][@c][:t] (comment might be a typo and it is actually g:a[:v][:c][@t]) https://github.com/bazel-contrib/rules_jvm_external/blob/6.5/private/lib/coordinates.bzl#L7
• g:a:v[:c][@t] https://github.com/bazel-contrib/rules_jvm_external/blob/6.5/private/lib/coordinates.bzl#L84

Maven doesn't seem to prescribe anything except for g:a:v for string representation whereas in pom.xml any combination is possible: group, artifact, version (optional if defined in dependencyManagement, or in scope of exclusions or like), type (same as packaging?), classifier, scope (defines how artifact is used but not which (sub)artifact)

It would be nice to map out where string versions are expected to be used and then go from there, ideally only keeping strings on the surface. Currently is seems some of the extra attributes have inconsistent levels support (different naming, being or not being included in generated pom, support for specifying at all, etc)

I'm also seeing a regression here in 6.6 vs 6.5:

maven.install(
artifacts = [
...
"me.friwi:jcef-api:jcef-7f53d6d+cef-100.0.14+g4e5ba66+chromium-100.0.4896.75",
"com.company:thing1:VX.2.5.0.0",
"com.company:thing2:VX.2.5.0.0",
....
],
)

In all the cases, the version numbers have alphanumeric characters in them.

For now, we are sticking with 6.5

@shs96c

g:a:p:

Just wondering is the plan to roll forward with the g:a:p: format?

@dmivankov

g:a:v[:c][@t] https://github.com/bazel-contrib/rules_jvm_external/blob/6.5/private/lib/coordinates.bzl#L84

Isn't this an 'export' format to match 'gradle' or some such? So it's not part of the possible inputs, only an output? Correct me if I misunderstood this case.

@dmivankov

g:a:v[:c][@t] https://github.com/bazel-contrib/rules_jvm_external/blob/6.5/private/lib/coordinates.bzl#L84

Isn't this an 'export' format to match 'gradle' or some such? So it's not part of the possible inputs, only an output? Correct me if I misunderstood this case.

that one might well be only used for export, I was trying to find all possible formats mentioned in the repo

Any progress on this issue? What would be a suggestion on user side to work around this? Switching to maven.artifact instead?

Sorry. I've been sick or busy with work since the start of the year. I'll try and make some time for this today or tomorrow.

I've prepped #1311 to try and address this issue.