Description
Is your feature request related to a problem? Please describe.
Support additional targets like jvm_jar/scala_jar with the purpose of packaging compiled JVM sources into JAR artifacts that can be published into a Maven 2 compatible repository.
Building JARs and publishing them is bread and butter in the JVM world and can be helpful in many scenarios but most beneficial in the following two:
- Library authors, specially multi-module frameworks, that want to have a single repo for all their sources (for consistency purposes) but want to offer a mix and match selection of features to their users.
- An organization wants to move from a repo-per-project structure to a monorepo but wants do to do that gradually so they can move repos one at a time. Without this feature they only have an all or nothing approach.
Describe the solution you'd like
The bare minimum would be being able to declare JAR artifact targets like in the following scenario:
jvm_artifact(name="thrid_party_1", group=..., artifact=...) # simplified for sake of brevity
jvm_artifact(name="third_party_2")
java_sources(name="core_src", dependencies=[":third_party_1"])
java_sources(name="extra_src", dependencies=[":core_src", ":third_party_2"])
jvm_jar(name="core_jar", group="my.org", arfifact="core", version="1.0", dependencies=[":core_src"])
jvm_jar(name="extra_jar", group="my.org", arfifact="core", version="1.0", dependencies=[":core_jar", ":extra_src"])With the previous, when running pants package ::, Pants would build two JAR artifacts, the ones for targets core_jar and extra_jar with only the minimal compiled sources according to the dependency graph that still produce a valid class path. So, since core_jar depends on core_src, it will contain only the class files for the core_src target AND NOT the class files for the third party dependency. In the case of extra_jar a similar thing happens but also the class files for core_src WILL NOT be part of the final JAR as they are already satisfied by the dependency on core_jar.
The built JARs should be publishable into a Maven 2 compatible repository. This could be achieved by leveraging Apache Ivy which would also give the possibility to publish to non-Maven repos. The choice of underlying mechanism is left open though but it's considered to be crucial for this feature as there is little value on creating JAR files that are not shared with others. Important to note is that to achieve the Maven 2 compatibility, Pants will need to generate a POM file and package it inside the JAR.
Additionally, the jvm_jar target should support being runnable (having a main field).
A scala_jar target type should also be supported at some point since, similar to the scala_artifact target, Scala JAR names need to be decorated with the Scala version. While this can be done using the simpler jvm_jar target and resolves, a scala_jar specific target simplifies it a lot.
Describe alternatives you've considered
There isn't much alternative right now, organisations that want to publish JARs need to rely on secondary tools to perform that specific task or just stick with their original built tool of choice (i.e. Maven, Gradle, SBT, ...).
For those that really want to transition to Pants, the path of less resistance is to use deploy_jar to build massive JARs and then use Apache Ant to unpack them and build smaller JARs based on folder structure.
Additional context
Authenticating with password-protected Maven 2 repositories at the time of publishing the JARs is out of scope at this point.
Activity