Bazel Maven Repository Rules v2.0.0 Alpha 5

All existing changes in prior alphas, plus:

• Duplicate entries in an artifact's deps are de-duplicated before BUILD files are written.

Bazel Maven Repository Rules v2.0.0 Alpha 4

All existing changes in prior alphas, plus:

• Unpacked .aars now don't just "deps" their unpacked classes.jar, they export them.
• Add a config option to set the default threadcount for metadata fetching.
• Add an env var mechanism to tune fetch threads. Set BAZEL_MAVEN_FETCH_THREADS to a positive integer.
• More careful filtering out of non-build-related dep scopes (i.e. system, which behaves weirdly with maven properties)
• Improved packaging handling in Kramer to recognize unhandled packaging types.
• Support include and deps configurations, to go beside exclude
  • include/exclude can work together, but not with deps which overrides the deps list, and build_snippet overrides everything.
• Handle aar's with /libs/*.jar
• Add a facility for overriding values via a settings.json file
  • presently only used to set mirrors to override repo urls, but may carry more per-environment configuration, such as auth credentials.
  • file location override-able with env var BAZEL_MAVEN_SETTINGS (for CI, or other cases of pointing at a different settings)

  • TODO: set a default (e.g. ~/.m2/settings.json)

• other minor fixes, cleanups, formatting.

Bazel Maven Repository Rules v2.0.0 Alpha 3

All changes from earlier alphas, plus:

• Ensure directories are created before attempting to write into them.

Bazel Maven Repository Release 2.0.0 Alpha 2

Note: Alpha release - see planned features and known issues

A mechanism for importing maven-based artifacts into a bazel build (an alternative to rules_jvm_external).

Bazel Maven Repository 2.0 uses a custom built download agent (Kramer, named for the archeologist Carol Kramer) and based on [Maven Archeologist] to quickly resolve and download maven metadata and construct a local bazel workspace representing that repository.

Features

• Single specification of a list of artifacts representing the "universe" (one-version per maven workspace)
• Caching via the standard maven ~/.m2/repository
  • md5 and sha1 hashes are checked for all files, per maven repository model resolution
  • sha256 hashes also checked on artifacts if given in the configuration)
  • artifacts without a sha256 hash must be listed as "insecure": True in the artifact config.
• Generates a bazel package path per maven groupId, and a target per artifactId
• Auto-computes of inter-artifact dependencies (from maven metadata)
  • supports configured (not detected) dependency exclusions
• Substitution of build-snippets (for wiring up dagger, etc.)
• Supports multiple maven repositories
• Supports jar, bundle and aar packaging
• Supports jetifier for android projects
• Tested with java and kotlin rules, including test rules.
• per-artifact build-snippet substitution (e.g. to wire in annotation processors, or fix mis-specified deps)
• per-groupId dependency target substitution (to fix internal build cycles created by build snippet substitution)
• Downloads (if available) source-jars and propagates them for IDEs to pick up.
• Tested against java, kotlin, and android projects.

Key improvements from 1.x

• Performance - 2.x (via kramer) performs highly-parallelized fetches and makes use of caching.
  Local developer rebuilds of the workspace (if artifacts are cached in ~/.m2/repository) are sub-second
  for anything under ~350 artifacts. Time required is technically linear but effectively trivial per artifact.
  At square, we regularly resolve 500+ artifacts in about 1.5 seconds on our developer laptops, and <10s
  on less powerful cloud CI workers (the workers don't get cache hits)
• Jetifier and dependency exclusions (from 1.2.x, but that was a short-lived release, so worth mentioning)
• Source jar support
• Improved appearance in Intellij's External Libraries list.
• In later alphas and betas:
  • Snapshot (sort of - available but frozen because of bazel hermeticity requirements) versions
  • multiple-workspaces

Planned features.

• SNAPSHOT dependencies (pending 2.0 release)
• multiple maven_repository_spec() calls (pending 2.0 release)

Known limitations

• Does not honor in-POM dependency excludes. In short, it can't. It builds a holistic view of the
  repository space, and excludes defined in maven poms trim transitive dependencies.

Known limitations in this alpha:

• Unspecified transitive closure:
  • Doesn't auto-download transitive dependencies not specified in the version list (under discussion)
  • version pin dictionary is in .bzl and given to the rule via starlark - this probably will remain to avoid
    failing to re-build the repository workspace on a version pin list change, but better examples and
    patterns and tool support are pending.

This release is very similar to the 1.0 release, with some additional features. Mostly it is radically faster, and it should be easier to iterate on future features.

Please see the README.md for usage instructions and examples of the above features.

Bazel Maven Repository Rules v2.0.0 (alpha)

Note: Alpha release - see planned features and known issues

A mechanism for importing maven-based artifacts into a bazel build (an alternative to rules_jvm_external).

Bazel Maven Repository 2.0 uses a custom built download agent (Kramer, named for the archeologist Carol Kramer) and based on [Maven Archeologist] to quickly resolve and download maven metadata and construct a local bazel workspace representing that repository.

Features

• Single specification of a list of artifacts representing the "universe" (one-version per maven workspace)
• Caching via the standard maven ~/.m2/repository
  • md5 and sha1 hashes are checked for all files, per maven repository model resolution
  • sha256 hashes also checked on artifacts if given in the configuration)
  • artifacts without a sha256 hash must be listed as "insecure": True in the artifact config.
• Generates a bazel package path per maven groupId, and a target per artifactId
• Auto-computes of inter-artifact dependencies (from maven metadata)
  • supports configured (not detected) dependency exclusions
• Substitution of build-snippets (for wiring up dagger, etc.)
• Supports multiple maven repositories
• Supports jar, bundle and aar packaging
• Supports jetifier for android projects
• Tested with java and kotlin rules, including test rules.
• per-artifact build-snippet substitution (e.g. to wire in annotation processors, or fix mis-specified deps)
• per-groupId dependency target substitution (to fix internal build cycles created by build snippet substitution)
• Tested against java, kotlin, and android projects.

Key improvements from 1.x

• Performance - 2.x (via kramer) performs highly-parallelized fetches and makes use of caching.
  Local developer rebuilds of the workspace (if artifacts are cached in ~/.m2/repository) are sub-second
  for anything under ~350 artifacts. Time required is technically linear but effectively trivial per artifact.
  At square, we regularly resolve 500+ artifacts in about 1.5 seconds on our developer laptops, and <10s
  on less powerful cloud CI workers (the workers don't get cache hits)
• Jetifier and dependency exclusions (from 1.2.x, but that was a short-lived release, so worth mentioning)
• In later alphas and betas:
  • Snapshot (sort of - available but frozen because of bazel hermeticity requirements) versions
  • source-jars
  • multiple-workspaces

Planned features.

• SNAPSHOT dependencies (pending 2.0 release)
• multiple maven_repository_spec() calls (pending 2.0 release)
• source jars (pending 2.0 release)

Known limitations in this alpha:

• Does not honor in-POM dependency excludes. In short, it can't. It builds a holistic view of the
  repository space, and excludes defined in maven poms trim transitive dependencies.
• Unspecified transitive closure:
  • Doesn't auto-download transitive dependencies not specified in the version list (under discussion)
  • version pin dictionary is in .bzl and given to the rule via starlark - this probably will remain to avoid
    failing to re-build the repository workspace on a version pin list change.

This release is very similar to the 1.0 release, with some additional features. Mostly it is radically faster, and it should be easier to iterate on future features.

Please see the README.md file for usage instructions and examples of the above features.

Bazel Maven Repository Rules v1.2.0

A release that basically skips 1.1, abandoning that branch and its performance regressions, adding in some features of that branch to the original 1.0 line.

Features include:

• Jetifier support (from 1.0.1)
• aar handling via android_library instead of aar_import (via 1.0.1)
• Templates now use raw_jvm_import and explicit path targets instead of maven_jvm_artifact(deprecated)
• Add support for dependency exclusions and testonly=true
• Make artifact targets able to contain - (e.g. dagger-compiler is now :dagger-compiler not :dagger_compiler)

This is a transitional release, during which the master branch was swapped, and forms the base (in terms of commit history) for the 2.0 release.

Bazel Maven Repository Rules v1.0.1

A small release including:

• Basic jetifier support
  • pulls jetifier 1.0.0-beta08
  • Runs jetifier on maven-fetched jars (if they're not excluded).
  • Configurable with an exclusions list (with globs) as well as an on/off switch.
• Stops using aar_import, instead exploding the .aar and using a proper android_library rule.
  • Fixes issues with R classes not propagating in some cases, and is a net performance gain.

Bazel Maven Repository Release 1.0.1 RC7

Includes all changes up to 1.0.1-rc6, plus:

• Improvements to configurability of jetifier.

Bazel Maven Repository Release 1.0.1 RC6

Includes all changes up to 1.0.1-rc5, plus:

• Fix to ensure that dependencies are properly propagated into the classpaths of unzipped .aars.

Bazel Maven Repository Rules v1.0.1 Release Candidate 5

All changes in Bazel Maven Repository Rules v1.0.1 Release Candidate 2, plus:

• Expands AARs instead of using aar_import, to obtain correctness and performance benefits.