JVM v2 plugin bikeshed: 

jvm_dependency

 , 

jvm_requirement

, 

jar_requirement

, 

java_jar_requirement

, 

jvm_jar_requirement

, or some other name?

What does a "pom" dependency mean? I get POM files, but what does depending on one mean for 3rd party deps?

maybe. not sure we want to highlight courier in defining a requirement. using coursier should just be an implementation detail. It isn’t essential to specifying deps to name that it also uses coursier to resolve.

With proposing

jvm_requirement

, you mentioned in the ticket that you would have a distinct

scala_requirement

. Can you share more about that? And if you've thought about other JVM languages like Kotlin?

I was reading through the PR comments, is the idea behind

jvm_dependency

that it would be reused by

scala_dependency

hence why it is more "general"? if so I believe that makes sense since someone with experience in scala could use the

jvm_dependency

and manually add the version suffix.

Oh, interesting: like

scala_requirement

generates

jvm_requirement

using the new target generation stuff? And you can also manually declare the

jvm_requirement

if you want? I could imagine something like

sbt_requirements

to parse an SBT config and generate

jvm_requirement

targets (@loud-stone-83419 not sure if you've seen that target gen stuff. tl;dr: we realized this week that Pants can be a lot more conceptually clear if we have distinct targets for the "atoms" of builds like

java_test

,

jvm_requirement

. And then separately targets for the sake of boilerplate reduction, like

sbt_requirements

and

java_tests

, which generate the atomic targets)

@loud-stone-83419: yes the

scala_dependency

would just override artifact and append the version suffix but users could still use the base form directly and append it themselves

So,

jvm_artifact

is the underlying atom. That makes sense to me. Do you know if that generalizes to other JVM languages like Kotlin? (I'm being lazy not looking, can if that's helpful.) cc @ancient-vegetable-10556

👀

Where that

scala_artifact

is adding for you the specialized runtime dep automatically? Under-the-hood, it is still a

jvm_artifact

?

in v1 or planned for v2?

I'm asking about what would be planned for v2. Trying to figure out with

jvm_artifact

, what would happen if a

scala_source

target depends on a

jvm_artifact

. Or if you need it to depend on a

scala_artifact

and

jvm_artifact

doesn't work. In other words, does

scala_artifact

simply generate a

jvm_artifact

for you to cut down on boilerplate, or is it fundamentally a different thing

they’d look exactly the same to coursier resolver, just coordinates to download

Oh yeah, true. I see what you mean. Sweet, not using target generator is much simpler

re naming, I’m leaning toward

jvm_artifact

and

scala_artifact

All jvm runtimes have this problem. Not all exposed it always. Its analagous to Python distribution wheel tags. S, the JVM got away with not having to worry about this ~forever since it evolved slowly and you could usually target compilation for published artifacts to a very old and stable JVM target. Scala moved fast and broke things, so they hacked a standard maven coordinate with a suffix on the name component that was the scala version. So you'd publish

org:name-<scala-rev-1>:ver

and

org:name-<scala-rev-2>:ver

If you were supporting more than 1 scala rev for the same artifact. Then Java started moving fast and breaking things and so now, since java 9 you can embed multiple classfiles per input sourcefile to target multiple JVMs at once: https://openjdk.java.net/jeps/238