| Age | Commit message (Collapse) | Author |
|---|
|
We are (ab)using an internal tool provided by `rules_jvm_external` and
its label changed.
|
|
This simplifies the setup for contributors as well as the release process. Since we can't use `--release 8`, we still need to check compatibility with Java 8 runtime libraries in our CI, which still uses the local JDK 8 to run tests against.
Also removes stamping from Maven builds as we already have the version number baked in.
|
|
|
|
The "driver" and the "agent" used to be separate components of Jazzer
that were written in different languages (C++ and Java), but this is no
longer the case: They are now mostly implemented in Java and deployed as
a single jar. The natural separation into Java packages rather than
top-level directories fits this architecture better.
This commit has been produced by moving the directory contents,
replacing `//(agent|driver)/` with `//`, running `buildifier -r .` and
manually editing non-BUILD occurences (e.g. .bazelrc, format.sh as well
as runfiles paths).
|
|
|
|
Linking javadocs against a remote endpoint makes the javadoc generation
non-hermetic and requires an internet connection for the build to
succeed. While this is necessary and acceptable for docs builds, it
should not be required to produce our Maven artifacts.
|
|
Getting clickable cross-references in Javadocs requires publishing the
docs in order, which is documented in the new `CONTRIBUTING.md` guide.
|
|
Before
https://github.com/bazelbuild/rules_jvm_external/commit/90280783fa4e74439b88191acafd99232ada61aa,
parent directories of files were not necessarily included in JARs
generated with `java_export`, which could confuse Java tooling expecting
them to exist.
|
|
`jazzer-junit` uses `FuzzedDataProvider` and should thus depend on
`jazzer-api` directly rather than just through `jazzer`.
|
|
|
|
|
|
|
|
|
|
For the same reasons as for jazzer_bootstrap, Jazzer should not need
Kotlin metadata. Having it on the ordinary classpath is potentially even
more troublesome.
|
|
|
|
The HEAD of rules_jvm_external now includes a check that would have
caught the issue fixed by e5e963ec997265c4953a516b63855c0ed712d116.
In addition, it allows us to directly depend on `java_export` in the
`data` attribute of a native rule such as `sh_test`.
|
|
`java_export` targets build deploy jars that bundle all implicit
dependencies. Since `java_binary`'s `deploy_env` attribute excludes
entire Bazel targets rather than individual classes, this doesn't work
if only intend to bundle parts of `java_export` target - in this case,
the fuzz target API but not the hook API.
Instead, we revert the main `api` target an ordinary `java_library` and
verify correct contents right on the jar we deploy to Maven.
|
|
|
|
|
|
|
|
Javadoc fails on neverlinked libraries. Since these libraries are
extremely small, it's not a problem to add them to the runtime
classpath.
Also reduces visibility of some classes that should not appear in the
Javadocs.
|
|
|
|
|
|
|
|
Now that we are managing more poms, having them all in deploy seems
better.
|
|
|
|
Since repositories.bzl no longer declares rules_jvm_external, depending
Bazel projects otherwise fail to parse the top-level BUILD.bazel.
|
