https://pantsbuild.org/ logo
#general
Title
# general
f

fast-nail-55400

09/16/2021, 7:16 PM
JVM v2 plugin bikeshed: 
jvm_dependency
 , 
jvm_requirement
jar_requirement
java_jar_requirement
jvm_jar_requirement
, or some other name?
h

hundreds-father-404

09/16/2021, 7:59 PM
What does a "pom" dependency mean? I get POM files, but what does depending on one mean for 3rd party deps?
Would
coursier_requirement
possibly work?
f

fast-nail-55400

09/16/2021, 10:18 PM
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.
h

hundreds-father-404

09/16/2021, 10:20 PM
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?
l

loud-stone-83419

09/16/2021, 10:20 PM
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.
h

hundreds-father-404

09/16/2021, 10:25 PM
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)
f

fast-nail-55400

09/16/2021, 10:27 PM
@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
indeed in Pants v1, this is what was done but via a BUILD-file macro
hmm v1 called that
scala_artifact
so maybe we do
jvm_artifact
and
scala_artifact
?
except that
scala_artifact
would use the Target API to just override the
artifact
field. and with a properly-defined
FieldSet
, the JVM resolve code wouldn’t care about the difference
h

hundreds-father-404

09/16/2021, 10:31 PM
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
a

ancient-vegetable-10556

09/16/2021, 10:46 PM
👀
@hundreds-father-404 Some JVM languages require specialised runtime dependencies (e.g. Scala, Clojure), Kotlin and Java artefacts should just run on a bare JVM. So you wouldn’t need a specific
java_artifact
but you would probably need a special
scala_artifact
, if that makes sense?
👍 1
h

hundreds-father-404

09/16/2021, 10:56 PM
Where that
scala_artifact
is adding for you the specialized runtime dep automatically? Under-the-hood, it is still a
jvm_artifact
?
f

fast-nail-55400

09/16/2021, 10:57 PM
in v1 or planned for v2?
in v1
ScalaArtifact
extended
Artifact
so was the “same”
in v2, I would just use a
FieldSet
to gather the fields
h

hundreds-father-404

09/16/2021, 10:59 PM
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
f

fast-nail-55400

09/16/2021, 11:00 PM
they’d look exactly the same to coursier resolver, just coordinates to download
👍 1
1
scala_artifact
is just a target with the same 3 fields as
jvm_artifact
except it uses a custom field subclass for the
artifact
field
no need for it to be a target generator
scala code can depend on either. (and technically java code could depend on either if it wanted)
👍 1
h

hundreds-father-404

09/16/2021, 11:02 PM
Oh yeah, true. I see what you mean. Sweet, not using target generator is much simpler
f

fast-nail-55400

09/16/2021, 11:04 PM
re naming, I’m leaning toward
jvm_artifact
and
scala_artifact
👍 2
helps that
scala_artifact
is a name from v1 too
e

enough-analyst-54434

09/17/2021, 3:31 AM
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
4 Views