teach tailor how to parse Maven pom.xml files for their JVM dependencies

[tdyas]

./pants tailor could be useful when migrating from Maven if it could parse Maven configurations and generate the correct jvm_artifact targets corresponding to the dependencies found in the pom.xml files. This script is a rudimentary example of doing just that.

[Eric-Arellano]

What about target generation instead? That way it can't become stale

[tdyas]

What about target generation instead? That way it can't become stale

As with anything, it depends.

I believe it will be confusing to have multiple ways of specifying dependencies. For Go, we only have a single way since we don't actually support specifying dependencies except through a go.mod. Whereas in the JVM world, we currently have the Pants "native" way (jvm_artifact) plus (assuming the target gen argument) every other way of specifying dependencies like Maven pom.xml, Gradle configs, etc. Moreover, those formats are general build configuration for their respective tools and not merely dependencies-only.

I'd rather provide an easy migration route into the Pants world and not take on the maintenance and support burden of having to support a multitude of ways of handling dependencies. Plus user confusion since those other formats are full-on build configuration.

(Plus pom.xml is very yucky XML configuration.)

If we support jar publishing, I might re-evaluate since we would want to allow the user to publish an explicit pom.xml or else auto-generate the published pom.xml.

[Eric-Arellano]

I believe it will be confusing to have multiple ways of specifying dependencies.

I don't think I buy that. Python has the explicit way with python_requirement, along with python_requirements and poetry_requirements, which do target gen. It's worked out well.

--

not take on the maintenance and support burden of having to support a multitude of ways of handling dependencies.

Why would the maintenance burden would be worse using target gen vs. tailor? Either way, we need to be able to parse the format to create jvm_artifact targets. Only difference is whether we store those in memory vs. persist them to BUILD files.

--

Okay, so to be clear: we don't anticipate using Gradle alongside Pants, for example? This is meant to be a one-time migration aid and you delete Gradle after switching to Pants?

If that's the case, how do you think that ties into incremental migration? It's a general goal of Pants that you can keep using your old build system while incrementally switching to Pants.