The + operator on dicts is deprecated and will be removed from future
version of Bazel.
Change-Id: I9f3db02f13c1c56c3afc4cc94b142513f0ae3908
(cherry picked from commit 4c8be85fcfc83582fad77684cff6044e828d4cb6)
If a plugin specifies Implementation-Vendor, adding it again in the
gerrit_plugin rule results in a duplicate entry and the following
warning at build time:
WARNING: Duplicate name in Manifest: Implementation-Vendor.
Ensure that the manifest does not have duplicate entries, and
that blank lines separate individual sections in both your
manifest and in the META-INF/MANIFEST.MF entry in the jar file.
This change is the same as done in bazlets project by David Ostrovsky.
Change-Id: Iac72c1d1dbe11877e4e2042d2e11c8966147d7a9
It seems that unzip implementation on Alpine Linux doesn't create target
directory. That caused documentation index generation fail with this
error message:
unzip: can't change directory to \
'bazel-out/k8-fastbuild/bin/Documentation/html.zip_tmpdir/Documentation/':
No such file or directory.
Change-Id: I6226bef5758b045ac55a7126d89fc47dac474d54
In the future versions of Bazel (starting with 0.7 or 0.8) += on lists
will behave like in Python, by mutating the left hand side list. If this
list is frozen it will cause a runtime error. To preserve the previous
behavior such lists should be either copied or the `a = a + b` syntax
should be used (which is completely equivalent with the old behavior of
+= on lists).
Change-Id: I3ef62e0c1f3b5ceca705ed4fa331122c3190991e
When invoking Documentation/replace_macros.py, bazel removes environment
using 'env -e', the python script includes '#!env python' shebang, the
result is python not found.
Alignment with js.bzl resolves the issue, explicit python removed.
Change-Id: If33baa7e7449f1a8a4a06cceefeb82dad2dc1577
Signed-off-by: Alon Bar-Lev <alon.barlev@gmail.com>
This fixes I850271bb1c657a5ffe77946a6beaf54a3680af75.
Change-Id: I128ae1b88adc267b0f1f9b1db7b0a96a87a861b3
(cherry picked from commit 9ffd58a82b497dbdfcf73945dea240469fee3b14)
Bazel 0.5.1 is using "bazel-out/darwin_x86_64-fastbuild/", which
failed these extraction patterns. Allow anything before the
-fastbuild part of the path.
Change-Id: I850271bb1c657a5ffe77946a6beaf54a3680af75
Introduce the CUSTOM_PLUGINS_TEST_DEPS in tools/bzl/plugins.bzl
that allow plugin with external test dependencies to be listed.
That way Eclipse classpath generation process can consider these
dependencies.
Because the plugin's own test rule need these dependencies, it
should expose java_library rule called: <plugin>__plugin_test_deps:
java_library(
name = "high-availability__plugin_test_deps",
visibility = ["//visibility:public"],
exports = [
"@byte-buddy//jar",
"@mockito//jar",
"@objenesis//jar",
"@wiremock//jar",
],
)
and re-use this rule in junit_tests rule, e.g.:
junit_tests(
name = "high_availability_tests",
[...]
deps = [
[...]
":high-availability__plugin_test_deps",
]
)
Bug: Issue 6351
Change-Id: I55b402fa6edb9f2506a91451d70e68d44d1a7762
Utilize the Closure compiler in Bazel to transpile. As part of this, a
rather large file of 'externs' must be added in order to call external
code. This file is specific to Polymer and copied from the Closure
Github, and should be synced any time there are major changes to
Polymer.
Test Plan:
- run `bazel build polygerrit` and verify that whitespaces are removed
from resulting gr-app.js file
- run `bazel build Documentation:licenses.txt` and verify that the new
dependency is listed in resulting
bazel-genfiles/Documentation/licenses.txt
TODO in later changes:
- Get closure optimizations working
- Explore sourcemaps possibilities
- Maybe use closure linting?
Change-Id: Ic358743dda7286fea3ac1e95a7991a92c96d6341
(cherry picked from commit 1ea918bd367c091fb4128ab33d8ca7c61cfe770c)
This is a preparation change for bumping rules_closure to the HEAD, that
we need to make transpilation from ES6 to ES5 actually work.
Since this commit: [1] rules_closure moved from using maven_jar to home
grown java_import_external rule. However, this introduced subtle
incompatibility issue: [2], because java_import_external mounts external
dependency under the root directory and not under the @foo/jar directory,
like native and our own custom maven_jar rules are doing.
This leads to the incompatibility, of how the external dependency are
consumed, with the consequence, that artifacts are not found by the
rule_closure rules, that were fetched with our own maven_jar rule.
To rectify, extend our maven_jar rule and generate additional BUILD
file in the root folder of the external dependency directory and alias
it to the real one generated in the @foo/jar directory.
For example, this BUILD file is now generated in root directory:
alias(
name = "javax_inject",
actual = "@javax_inject//jar",
)
This allows us to omit additional fetching of already fetched artifacts
that are needed by rules_closures rules and let them reference to the
downloaded artifacts in gerrit build.
There is one complication though: java_import_external accepts deps
attribute, in which case the artifacts with dependencies are not
compatible with our own maven_jar custom rule, that doesn't support
transitive dependencies. That means that we can only reuse such
artifacts from the rules_closure build that don't have dependencies.
Another problem, why we can't reuse even such artifacts that don't have
dependencies specified, is different naming convention. gerrit uses
simple names, like jsr305, but rules_closure is using canonical artifact
names, e.g.: com_google_code_findbugs_jsr305, so that we get:
* external/jsr305/jar/jsr305-3.0.1.jar # gerrit
* external/com_google_code_findbugs_jsr305/jsr305-2.0.3.jar # closure
Effectively, right now this change let us only reuse 3 common
dependencies:
* aopalliance
* javax_inject
* args4j
Because the same name, we must solve the collision problem here. Another
considered alternatives to this change would be:
1. Ask rules_closure project to migrate to consuming their dependencies
from @foo/jar directory, so that it is compatible with native and custom
maven_jar rules
2. Consume common dependencies in gerrit with rule_closure's own
java_import_external rule
[1] a47cc063d3
[2] https://github.com/bazelbuild/rules_closure/issues/200
Change-Id: I31e6b863e43adaa1f983a8a9da1675f02cb803f8
(cherry picked from commit b5099530084deb61fcb9e60314579dd0daed79b5)
This change fixes Eclipse project generation when jgit is consumed from
external repository. Only path to the library is added, but not the
sourcepath.
Test Plan:
* Switch to using jgit from external repository by amending the path
in lib/jgit/jgit.bzl
* Run tools/eclipse/project.py
* Verify that classpath entries are added to the .classpath file
Change-Id: I2bdadb74b3ef869805a96671b7882917967998d6
We cannot shade bouncycastle in the plugin API. Still we need it to be
included in the gerrit.war, licenses file and Eclipse classpath.
Expose bouncycastle libraries in PLUGIN_TEST_DEPS constant, so that
the plugins don't need to change anything in tree build mode.
gerrit_api() bazlet in bazlets repository is extended too, so that the
plugins don't need to change anything in standalone build mode.
One side effect of this change, is that bouncycastle libraries are
now listed with neverlink suffix, e.g.:
* bouncycastle:bcprov-neverlink
Bug: Issue 5826
Change-Id: Idb8051e16b14e20c8dd528783ab297ee25707bb3
Now that Bazel build for JGit is fully implemented, we can document
the process of routing the JGit dependency to the development tree
instead of consuming it from Central or ~/.m2 local repository:
1. Activate local jgit repository in WORKSPACE file:
local_repository(
name = "jgit",
path = "/home/<user>/projects/jgit",
)
2. Uncomment alias to jgit repository in lib/jgit/**/BUILD files.
It shouldn't be needed and is tracked under this issue upstream: [1]:
alias(
name = "jgit-alias",
actual = select({
"@//lib:jgit-dev": "@jgit//org.eclipse.jgit:jgit",
"//conditions:default": "@jgit_lib//jar",
}),
visibility = ["//visibility:public"],
)
Test plan:
Update local JGit tree, run tests and verify that local JGit tree
modifications are relfected in gerrit build:
$ bazel build --define jgit-dev=1 headless
To consume JGit from Central, do not pass jgit-dev=1:
$ bazel test ...
[1] https://github.com/bazelbuild/bazel/issues/2707
Change-Id: I1b0fee7df802f6cbd54acbb0bc73157e2b8bc7cf
Change I5fc96bf1f removed the generation of the .primary_build_tool
file and change I3d6b90320 removed the build system abstraction with
the motivation that we now only have one build tool.
However this broke launching the daemon from Eclipse on MacOS, which
now fails because bazel is not on the path and can't be found.
Restore the removed functionality, but rename the file to .bazel_path
Change-Id: Ibd0ec09d3bf47f383ca68a37cca4e81640960416
You may want to pass arguments to the bazel build command line when
publishing, perhaps to debug output, or perhaps to add standalone flags
to avoid sandboxing on platforms where it is broken.
Change-Id: Ia1a9a50e7b833eea7299d9473dec87e4978b7803
This was introduced to support both buck and bazel build tools, and
is no longer necessary since we completely dropped buck in favor of
bazel.
Change-Id: I5fc96bf1fc27f20180737fea954e150070e5302f
Some platforms either don't have bash installed as /bin/bash. Use
the environment to find it in the PATH.
Change-Id: Ie1a6d64146927c83af07d0e2ca7f573c7504f8ef
The new settings are in line with the current Google Java Style Guide.
As the google-java-format plugin is better suited to enforce the style,
I added an additional section for it.
Change-Id: I7d9b10e17f1a00624dfd165cf0c9b09a5ff26f67
1164e53283187b8a2a79052f5ea85471f6f0b6d4 (Allow to add custom core
plugins in release build, 2015-12-11) added an item CUSTOM to the buck
plugin rules to make it easier for people to add additional 'core'
plugins in a release build of a forked copy of Gerrit.
When that was ported to bazel, it included cookbook-plugin by mistake.
As a result, when someone runs
bazel build release
they get a copy of gerrit with the cookbook plugin included and
enabled, which is almost never what they wanted.
Fix it by making the default list of custom plugins an empty list again.
Change-Id: I9b1653046bd368b8ec5c1978a15bd675c5dd31e7
This change fixes the following issues:
* server needs bcpkix for parsing public/private keys.
* do not special-case "jdk15on" in pkg_war.
We only have these in the BC jars.
* remove BC specific license checking exceptions.
* remove language about requiring BC installed separately.
* remove BC special-casing from eclipse setup.
Tested:
rm bin/* lib/* in testsite
ran 141 -> 142 schema upgrade successfully
ran daemon successfully
LICENSE.txt in war file has an entry for the BC license
Loaded new project in eclipse; verified that BouncyCastleUtil.java loads.
Change-Id: I80c2b0c038ada8397b44373194bd199f491a39c3
This allows us to pass additional parameters to gerrit_plugin:
gerrit_plugin(
name = "secure-config",
javacopts = ["-Xep:InsecureCryptoUsage:OFF"],
[...]
Change-Id: Ibcd328fc970fe65b33de789081a07bf0f1a0969f
Don't use the "readlink -f" as the -f option doesn't work the same way
on Linux and Mac.
The idea for this fix is borrowed from a similar fix done in Buck [1]
in this commit [2].
[1] https://github.com/facebook/buck/issues/1017
[2] f97b55c23c
Change-Id: I59cf184e184b09c1fabf0403012fd03b40d6732d
google-java-format is not uniformly available in package management
systems across OSes. More importantly, we want to make sure that all
contributors are using a standardized version, to avoid unnecessary
changes due to slight differences between versions.
While we're in the dev documentation, link to the Google Java Style
Guide, and remove some wording that is clearly redundant with the style
guide.
Change-Id: Ib14dab2e692339f836083fad08a7a435a2f24470
In some cases there is extra postprocess step to the final plugin
artifact. Expose target_suffix attribute in gerrit_plugin rule
to support this use case.
Change-Id: I9c7bf92e0c29c1962efb9c7e1c188d8f131713bb
The 'seed' packages are the ones whose versions are set by us in
WORKSPACE. We should not set the versions for the rest of the packages
in the bower input JSON, so bower can suggest the right versions to
use.
Change-Id: I9b75f16655d049e2064726862980a339c91dd534
Use the full word grep matching on the list of versions
when generating the correct plugin mame in a jar.
Previously, with a substring matching a plugin like 'owners'
resulted in multiple matches and thus generated an invalid
manifest file.
Change-Id: I9fda43aef42b2d46bd2be64e6e9e7425d1a0b7fe
Since the project.py script was removed along with the buck-based
build, it's not necessary to keep the _bzl suffix on the script for
the bazel build.
Change-Id: I3f97cab5cc0e855a5dc1865bb4cc00c18adea2e9
Otherwise, the shell may interpret [a-z], leading to version strings
such as
STABLE_BUILD_superm[nifest_LABEL 6010213-dirty
Change-Id: I5846efc03419e7361d3171df14646c96f66118ac
Currently, the GWT UI zip files contain some empty bazel directories:
$ unzip -l bazel-genfiles/gerrit-gwtui/ui_optdbg.zip | grep bazel
Archive: bazel-genfiles/gerrit-gwtui/ui_optdbg.zip
0 2016-12-20 09:57 bazel-out/
0 2016-12-20 09:57 bazel-out/local-fastbuild/
0 2016-12-20 09:57 bazel-out/local-fastbuild/genfiles/
0 2016-12-20 09:57 bazel-out/local-fastbuild/genfiles/gerrit-gwtui/
These end up making it into the WAR files, which is unfortunate. The
easiest way to eliminate these is to just omit all directories from
this one intermediate zip file. As there are several other
intermediate zip files, we actually still end up with directory
entries in the output WAR, just not these garbage ones.
Change-Id: I32bb39acc4d32207f9e006486cbba47fc06e0be0
Instead, use a hard-coded map of licenses.
Hardcode a false dependency on diff-match-patch to avoid a diff for
the Apache2.0 license.
Tested:
bazel build Documentation:js_licenses.txt
buck build Documentation:js_licenses.txt
diff -u buck-out/gen/Documentation/js_licenses.txt/js_licenses.txt \
bazel-genfiles/Documentation/js_licenses.txt
diff shows only diffs for added [[header]] anchors.
Change-Id: I7886e1fadec900cf854a1b3b7c538b83d66af7a4
Given that the feature request: [1], still wasn't implemented, expose
neverlink artifact for every artifact per default. This is needed to
support in Gerrit tree build for plugins, because every dependency
can be potentially used from a plugin, in which case it must be used
in neverlink form to avoid shipping it twice, in plugin artifact in
addition to gerrit.war itself.
With this change in place, we can write this build rule:
gerrit_plugin(
name = "verify-status",
[...]
provided_deps = [
"@commons_dbcp//jar:neverlink",
],
[...]
that would now work in both build mode: standalone (using bazlets) and
in Gerrit tree mode.
[1] https://github.com/bazelbuild/bazel/issues/1402
Change-Id: I1240d25c576b13bd4d7450a0e5ba143df27a3d3a
Given that Bazel activates error prone static analyzer per default,
allow to activate it for Buck as well. We already monkey patch
java_library and java_test rules, so it's trivial to munge javac_jar
and compiler_class_name attributes as well.
Due to compile performance coniderations and some issues that were
reported with error prone activated by default in Buck driven build,
we make the integration optional and disabled by default. There are
two option to activate it:
1. Add these lines to your private .buckconfig.local to permanently
activate error prone checks:
[sanitizers]
error_prone = 1
2. Use this config option to instantly run error prone check:
buck build --config sanitizers.error_prone=1 gerrit
Error prone has an issue with naming artifact with all transitive
dependencies included: while it has the suffix "ant", it should be
just called "all". But, TBH, we don't care.
Error Prone is Google library and is released under Apache 2 license.
Change-Id: I2bbe0313ad3e54df1d52968cc28d7e13db36d83f
