Setup Binary Deployment

[tyvsmith]

Setup binary deployment for consumers to utilize instead of clone only configuration.

[murray-stripe]

I'd like to make a proposal for at least part of this issue (and willing to contribute if we can agree on the approach).

Specifically for the aspect and the jars that it requires to run, I think we should create a separate deployable that can be pulled into a Bazel project. Currently the README instructs users to create a bazel module and also requires specific versions of Java and rules_python. This creates a fairly high barrier to use.

If we could create a separate artifact that folks could pull into their bazel projects; I would expect the contents of that deployable to look something like:

- aggregator_deploy.jar
- extractor_deploy.jar
- decompiler_deploy.jar
- semanticdb_javac.jar
- scip.bzl
- config.template
- BUILD.bazel

The deploy jars would be artifacts from building the Java deploy jars; the output of running

bazel build \
    //src/main/java/com/uber/scip/extractor:extractor_bin_deploy.jar \
    //src/main/java/com/uber/intellij/jd:decompiler_bin_deploy.jar \
    //src/main/java/com/uber/scip/aggregator:aggregator_bin_deploy.jar

scip.bzl and config.template can just be copied over from source and the contents of a BUILD.bazel file would roughly be:

java_import(
    name = "aggregator_jar",
    jars = ["aggregator_bin_deploy.jar"],
)

java_import(
    name = "extractor_jar",
    jars = ["extractor_bin_deploy.jar"],
)
java_import(
    name = "decompiler_jar",
    jars = ["decompiler_bin_deploy.jar"],
)
java_import(
    name = "semanticdb_javac_jar",
    jars = ["semanticdb-javac.jar"],
    visibility = ["//visibility:public"],
)


java_binary(
    name = "aggregator",
    main_class = "com.uber.scip.aggregator.Aggregator",
    runtime_deps = [
        ":aggregator_jar",
    ],
    visibility = ["//visibility:public"],
)

java_binary(
    name = "extractor",
    main_class = "com.uber.scip.extractor.LombokJarProcessor",
    runtime_deps = [
        ":extractor_jar",
    ],
    visibility = ["//visibility:public"],
)

java_binary(
    name = "decompiler",
    main_class = "com.uber.intellij.jd.Decompiler",
    runtime_deps = [
        ":decompiler_jar",
    ],
    visibility = ["//visibility:public"],
)

This could then be pulled into any bazel project as an http_archive or similar.

Some additional considerations and challenges:

• The current version of Java, configured at 21, is unnecessary. Currently we can compile and run these targets with 17 and we should probably opt for the lwoer version for wider compatibility.
• The aspect will need to reference private inputs from a different location. We'll need to decide whether we want to change the main aspect (which would make it unusable in the current flow), or template it out separately when packaging.

I'd imagine that we'd like to set this up as a github workflow?