Fabian Meumertzheim

I checked the docs and I think that this would only be possible for non-module projects via [`+incompatible`](https://github.com/golang/go/wiki/Modules#can-a-module-consume-a-v2-package-that-has-not-opted-into-modules-what-does-incompatible-mean), but we certainly want to keep the `go.mod` for buildtools. Which essentially...

@vladmos You don't need to edit existing versions. Since they lack the `v` prefix, they are being ignored by any kind of Go tooling anyway. New versions would need to...

@vladmos Those versions are also ignored as they violate the path structure: any vX.Y.Z with X>=2 needs to be in a `vX` directory. So you don't need to edit those...

Yes, NPM is (presumably) different. I was just referring to the Go versions. You could continue publishing `7.2.0` versions for NPM and `0.7.2` versions for Go. Both don't allow four...

We could add a `remote_files` attribute to `http_archive` that takes a dict from repo-relative paths to URLs and downloads the files from these URLs to the given path (for simplicity,...

@fzakaria That's highly appreciated! Your research looks solid, most of this can indeed be done in Starlark and I can also help with the Java parts. For starters, I would...

OSS-Fuzz uses the native `jazzer` binary primarily for backwards compatibility. You can just as well use the ordinary `jazzer_standalone.jar` provided in our release. Since OSS-Fuzz currently [uses Jazzer v0.17.1](https://github.com/google/oss-fuzz/blob/fd5ae388d5db3de661e70c5ab91a45e96188f7f9/infra/base-images/base-builder/install_java.sh#L32), you...

@linzhp Do you see any reason to keep these around?

As this is only used for certain special binaries that are typically built very early in a build, I am slightly surprised to see this contribute to your critical path....

This looks good to me, but could you add test coverage? I don't really know how these files work, but adding a `go_test` with such a file in `srcs` somewhere...