Proposal: Expand Bazel default tools workspace to include more "SDK" elements for rule development.

[hsyed]

I haven't re-visited the default workspaces for a while and I didn't do a thorough enough investigation last time when I looked; so apologies if parts of what I am asking for already exists.

When I ported the Kotlin rules I removed all non essential third party libs (guava, dagger, etc) since they weren't really adding much value.

I would make use of the following elements if they were available:

1. Misc java libraries (guava, protobuf-java, truth, Gson etc).
2. All relevant bazel Java proto jars and proto files (I've inlined compiled versions of jdeps and worker protocol).
3. Protoc compiler for the host platform: so many external repos depend on protoc -- this takes a significant amount of time on my Mac Pro to compile. On laptops -- ouch. Kotlin Rules don't depend on this but lots of other components pulled into a large mono repo do.
4. Parts of the JavaBuilder as a library I am reinventing many wheels -- I couldn't say what parts are useful to me now but the KotlinBuilder does a lot of the stuff that the JavaBuilder does.

All of the mentioned libs in 1-3 are either in the Bazel or Google domain so API evolution is strict as can be.

[laszlocsomor]

pulling in @dslomov and @laurentlb , because this request relates to extensibility and to workspaces

[hsyed]

@hchauvin is working on coverage support for the kotlin rules. These require the asm and jacoco deps. I've just had a look through the bazel tree and the deps are used in bazel core. Could these be made available ?

[hchauvin]

@hsyed I think it makes sense as well, since making the jacoco dep available would allow, as far as I can tell, all the JVM-based languages to be instrumented without pulling any external dep and to be in sync with what bazel core is using.

Alternatively, if the JavaBuilder is exposed, I could probably use com.google.devtools.build.buildjar.instrumentation.JacocoInstrumentationProcessor directly.

[ittaiz]

@dslomov any thoughts? I'm not sure this suggestion is the way to go but I think the need to be able depend on some of the java parts (jdeps read/write for example) is a standing issue

[hsyed]

A bit of an update since some time has passed. I'm quite satisfied with the dep footprint of rules_kotlin currently.

Recompilation of host Protoc, the proto java deps(gson, protobuf_java, protobuf_java_util) and the core precompiled protos are my current pain points. Should we narrow the scope of this issue down to just proto ? The concept of sharing other deps (asm / Jacoco etc) could be revisited in other isses

[philwo]

I'm sorry, I don't understand what is asked for in this issue. What is a "default workspace"? What's the current behavior and what's the expected behavior of Bazel?

[ittaiz]

I'm not the original OP but I think the idea was about tools bazel ships with precompiled

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[github-actions]

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!