Switch transitive dependencies from runtime to compile

[kshakir]

Description

In the POM file generated for Picard, dependencies are all listed as runtime. However, if one wants to use Picard as a library, they end up having to explicitly include Picard's dependencies instead of them being implicitly added to the downstream project.

This changes the generated POM file, switching dependencies from runtime to compile.

• For the old POM using runtime, see:
  https://repo1.maven.org/maven2/com/github/broadinstitute/picard/3.1.1/picard-3.1.1.pom
• Gradle docs on runtime vs. compile: https://docs.gradle.org/8.4/userguide/java_library_plugin.html
• Maven docs on Dependency Scope options: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#dependency-scope

---

Checklist (never delete this)

Never delete this, it is our record that procedure was followed. If you find that for whatever reason one of the checklist points doesn't apply to your PR, you can leave it unchecked but please add an explanation below.

Content

• Added or modified tests to cover changes and any new functionality
• Edited the README / documentation (if applicable)
• All tests passing on github actions

Review

• Final thumbs-up from reviewer
• Rebase, squash and reword as applicable

For more detailed guidelines, see https://github.com/broadinstitute/picard/wiki/Guidelines-for-pull-requests

[kshakir]

Chatted w/ lbergelson. I'm going to try out a more restrained list of api dependencies with our code and will report results back here.

[kshakir]

Closing this PR.

https://github.com/broadinstitute/Drop-seq uses multiple dependencies that are also used by Picard. For example, we use the HTSJDK and barclay, but also some of the same Apache Commons libs too.

But Drop-seq doesn't have an easy mechanism to keep these transitive dependencies in sync with Picard. In a Maven project that would be easy as the dependencies would be compile by default (aka api in Gradle DSL). But with transitive dependencies listed as runtime (aka implementation in Gradle DSL), Drop-seq would have to sync up our dependencies whenever we updated Picard.

Another alternative would be to try dependency version ranges in Drop-seq, but I'm not too familiar with setting up a Gradle project that way.

Instead, we will stick to including the entire Picard executable jar, transitive dependencies and all. That way, whenever we bump the Picard version, we also upgrade Drop-seq's transitive dependencies to the versions tested with Picard. No dependency hell, and our shaded/assembled Drop-seq jar is the same size as we would likely get by just including all of the Picard dependencies anyway.

[lbergelson]

I don't really follow what you're saying. Anytime you update your picard dependency in dropseq all the implementation dependencies should be updated in sync with it automatically by gradle. Typically I believe gradle dependency takes the highest requested dependency version unless you other rules applied explicitly. So your runtime dependencies will be max(picard version , dropseq version) unless otherwise specified. The only time this should be problematic is if there is a misdeclared picard implementation dependency which makes a change from compile -> runtime in an unexpected way. Or if your dropseq code relies on an older version of a transitive depedency which picard updates, but thats a problem with the way you're doing it too...

I think this is a valuable change to make here anyway so I guess I'll take it over.