The tooling in it's current state is not realistic for Java Microservice codebases.

[hsyed]

Bazel is fantastic and I am very happy with the characteristics of our Build. I am writing quite complex rules for our build now as we have specific packaging and launch requirements.

The tooling in this repo works fine for well defined workspaces with a few top level entries. I started our port to Bazel using the tooling here and quickly gave up.

To give you some scope -- at the moment I have partially ported our Java codebase to Bazel. I have 250 ~ external jars. There are a lot of dependencies which have huge transitive chains and conflicting common dependencies -- For example: Jersey, Spring-Data-JPA. Soon I need to update some of these dependencies and I can't see how I would realistically do that with the rules here.

To port our repo I took the approach of writing a shell script for the tooling here and then adding the dependencies incrementally. Each new dependency increased the cycle time. It was unbearable by the 10th or so dependency.

The transitive rule / macro provided is a non starter for a large project as well.

I ended up usingthese rules.

The following elements are key I think:

• A dedicated dependency resolver: the rules above use Gradle (which uses Ivy I think).
• Something serving as a lock file: The rules above spit out the transitive closure of the dependencies which have to be pasted back into the rules.

The approach isn't perfect as I still need to clutter my workspace with boilerplate, and I need to manually paste the transitive block in.

The Kubernetes project -- a go project uses the two elements above as well. The vendored dependencies are managed by dep and thus a lock file. And dep serves as a fast resolver.

It would be great to have a tool like the go dep tool, something that calculates a transitive dependency block and locks it and a file format that Bazel core understands.

[ulfjack]

@hsyed, thanks for your feedback. I'm not sure what you mean when you talk about a lock file - can you elaborate how that'd work? If it needs Bazel support, then we'll also need to file a feature request over in the Bazel issue tracker...

[hsyed]

@ulfjack sorry for the delay I missed your comment.

I've created an issue on pubref/rules_maven to bridge them in.

Currently the pubref/rules_maven work as follows:

1. Express dependencies in a rule. Pubref then uses Gradle to Resolve all the transitive dependencies. It generates a list of the dependencies with SHA hashes in a external workspace (W1). The transitive block has to be pasted back into the rule.
2. W1 contains compile rules for the Gradle configurations. These need to be loaded back into the workspace.

The approach works well but it is still inconvenient to modularise the dependencies. One thing that would help is support for load in macros. I added my 2cp to this issue in bazel core.

A lock file in this case not only locks the dependency stack of a workspace but Bazel core should load the file and setup the external workspace targets. The means thats once we have a lock file setup we don't need any external tooling.

Perhaps a lock file could look like this:

k8sclient:
  deps:
  - io.fabric8:kubernetes-client:2.6.2
  force:
  - com.fasterxml.jackson.core:jackson-databind:2.7.7
  - com.fasterxml.jackson.core:jackson-core:2.7.7
  - org.slf4j:slf4j-api:1.7.25
  configurations: 
    compile:
    - 19f42c154ffc689f40a77613bc32caeb17d744e3:com.fasterxml.jackson.core:jackson-annotations:2.7.0
    - 1b45281e277d07ef8c02e9726daef1175442759a:com.fasterxml.jackson.core:jackson-core:2.7.7
    - ...
    runtime:
    - 
grpc-all:
   ...

Notes:

1. Expresses multiple dependency groups in one file.
2. Bazel core does not handle dependency resolution and does not need to be involved in the generation of the lock file (separate tool). The pubref rules work great for now. Perhaps in the future an ivy resolver can be build into Bazel core.
3. Bazel core supports this file format it sets up a java_library for each configuration. For k8sclient it would generate the targets @k8sclient//:compile.