commons-lang is already exposed in the plugin API. Given that some
plugins depend on commons-lang3, expose it too, to make building
the plugins against it easier.
Change-Id: I16e2dda225738b24489da810f43d8148af39acbf
This allows plugins to support in tree Gerrit build.
Reported-By: Hugo Arès <hugo.ares@ericsson.com>
Change-Id: Ice25958041d4fb455f75bb3d63f62e08934c9ae6
Reformat the Bazel build files with the buildifier tool [1].
The style is different for Bazel files. Most notably, indentation level
is 4 spaces instead of 2, and " is used instead of '.
[1] https://github.com/bazelbuild/buildifier
Change-Id: I95c0c6f11b6d76572797853b4ebb5cee5ebd3c98
Currently too big files are published, because some unwanted transitive
dependencies are included in the final artifacts. That will be fixed in
follow-up change by using neverlink option in java_library rule or using
provided_deps attribute that will be addded in future releases of Bazel:
[1].
TEST PLAN:
$ VERBOSE=1 tools/maven/api.sh install bazel
$ VERBOSE=1 tools/maven/api.sh install buck
* [1] https://github.com/bazelbuild/bazel/issues/1402
Change-Id: Ie73d4ae34d96be7f97f6329c4c30c814f54688d5
In Ieb3666281 prolog compiler was exposed in the plugin API. Turns out
that same plugins also need prolog runtime. Add it as well to simplify
the build for those plugins.
Change-Id: I22b74b8c9c13d529d65cb664173d23d7430b50a4
I did not change the archetype version referred in the dev documentation
in case documentation need to be updated before 2.13.1 is released.
Change-Id: I5bef5050da4e5f1cbe46041a2ba605e8b192aa6e
Add javadoc rules for plugin API:
* gerrit-extension-api
* gerrit-plugin-api
* gerrit-acceptance-framework
Note that GWT UI is not covered by Bazel build yet, so that we cannot
offer gerrit-plugin-gwtui:plugin-gwtui-javadoc rule in this change.
TEST PLAN:
bazel build gerrit-acceptance-framework:acceptance-framework-javadoc
bazel build gerrit-extension-api:extension-api-javadoc
bazel build gerrit-plugin-api:plugin-api-javadoc
Change-Id: I60832752010118e33eb6a06529032d86f169ee44
To pubish to Maven Central, sources and javadoc artifacts must be
created. Bazel java_library and java_binary rules provide sources out
of the box. We need to combine single source artifacts (server, httpd
and sshd) in ueber JAR and use java_binary rule for it.
TEST PLAN:
bazel build gerrit-plugin-api:plugin-api-sources_deploy.jar
Change-Id: Iafb549b5d0c0b0d7749f301b1edbd48b167eea3b
javadoc accepts source archive and we need to create one anyway. So
instead of trying to use the sources in the tree and guess the root
project directory, just use the source archive. We extact the archive
in temporary directory to make javadoc work.
Change-Id: Ib605f6cdab4742a23789da8fbc9c963c83e5b6d9
This change lays the groundwork for migrating email templates from VTL
to Soy (Closure Templates). This change does not modify the existing
template system or how emails are constructed. Moreover, it makes the
Soy library available alongside the Velocity library.
With this change, the Soy library (along with its dependencies) is added
to //gerrit-server:server and //gerrit-plugin-api:lib. A new license
definition is included for ICU4J.
A Guice provider for SoyTofu objects (which work as factories for Soy
template renderers) is injected into EmailArguments similarly to
VelocityRuntimeProvider.java. For technical reasons, a Soy template is
included, but is not used at this time. It does, however, provide a
simple example for how the email templates may look soon.
Feature: Issue 4345
Change-Id: I9625de1d129c04770d2a2dcfd4967c2c2779a81c
If no manifest file is specified, Buck's java_binary() rule merges the
content of manifest files from the dependant JARs into output
META/MANIFEST.MF. Normally we wouldn't care that it ends up with a lot
of mess, but unfortunately, it breaks the plugin-api.jar, with sealed
package exception, so we do care.
This happens because we provide the same package in multiple JARs, e.g.
com.gerrit.server.project
is shipped with plugin-api.jar, obviously, but it happens that one file
Util.class, from the same package is shipped in the
gerrit-acceptance-framework.jar
artifact. Normally it doesn't matter, unless a JAR is defined as sealed
in which case security violation exception is thrown during unit tests
execution.
To rectify this, we use the combination of custom manifest_file
attribute of java_binary() rule and passing non documented option from
this issue: [1] to ask Buck to not merge manifest files from the
dependant JARs.
With this fix, plugin unit tests executions in standalone build mode
work again.
* [1] https://github.com/facebook/buck/issues/86
Change-Id: I7b7571c20dcf6b54210b73760eccc8e699e6f1f6
So it can be used in plugins without them having to define it
themselves (potentially with a different version).
Change-Id: Ibb15acdd75640cd18b21ad5ac5895fd164cebccd
* stable-2.12:
ChangeIT: Assert that submitting a change doesn't remove non-voting reviewers
Instead of deleting patch-set-approval set vote to zero
ChangeIT#commitFooters: Fix setup of test labels
CreateChangeIT: Fix flaky test
Add a testing method to set the clock step used by TimeUtil
Update issue tracker URL in documentation
Update issue tracker URL in POM files
Change-Id: I991be7faf90cd37a8d664a0c951fea4c14f94492
Some plugins depend on prolog, e.g. gerrit-owners plugin, so we make it
available for the in tree plugin build mode.
Change-Id: Ieb3666281d00f62a219c0870b67f65d0a9ed0f0e
To run the tests:
bazel test //...
To build the Gerrit plugin API, run:
bazel build gerrit-plugin-api:plugin-api_deploy.jar
To build the Gerrit extension API, run:
bazel build gerrit-extension-api:extension-api_deploy.jar
TODOs:
Licenses
Reduce visibility (all public for now)
Generate HTML Documentation
Core plugins
gerrit_plugin() rule to build plugins in tree and standalone modes
GWT UI (only gwt_module() skylark rule is provided, no gwt_binary())
PolyGerrit UI
WAR
Publish artifacts to Maven Central
Ask Bazel team to add Gerrit to their CI on ci.bazel.io
Contributed-By: Han-Wen Nienhuys <hanwen@google.com>
Change-Id: I9a86e670882a44a5c966579cdeb8ed79b1590de3
This will allow plugins to use the functionality without having
to explicitly declare a dependency.
Change-Id: I92aa3bb2e77deef433a7f1262d8ad5bda59dd83b
If047c3a2 added '//lib/bouncycastle:bcpkix' library to dependency of
'gerrit-sshd:sshd', but missed to add it to the javadoc generation
rule.
Change-Id: I6fb88abec41efe011789e23cf43a53ca96abbcaf
I39f2d5d7 isolated jgit in its own cell, that is based on this JGit
Buck build implementation: [1]. Migration was done seamlessly, meant
that single BUCK file in lib/jgit represents JGit cell root location.
However, the real structure of JGit project is divided to number of
different sub-projects. To map between simplified JGit cell in gerrit
and real JGit project structure in JGit project, java_library() rules
were added to root BUCK file in JGit project that work like proxy to
real rules located in JGit sub-projects. For example //:jgit in JGit
tree was implemented as:
java_library(
name = 'jgit',
exported_deps = ['//org.eclipse.jgit:jgit'],
visibility = ['PUBLIC'],
)
Such proxies are needed for every artifact that is referenced from
gerrit build and make Buck build implementation unnecessary verbose.
Moreover this introduced some subtle issues, like using JGit
dependencies in context of java_doc rules, where $(location :foo) macro
is unable to resolve the underlying files because java_library with
exported dependencies only do not have association with output file.
An attempt to replace java_library with only exported dependenies with
prebuilt_jar: [2] that depends on the real artifact introduced another
problem with assembly of gerrit.war, because now jgit.jar is twice in
the classpath (because prebuilt_jar has output file association). To
fix this we would need to filter potential duplicates in the assembly
process of gerrit.war.
Instead of using proxy approach and to try to provide yet another
workaround to subtle problems, emulate the JGit project structure and
reference directly the same artifacts paths within gerrit JGit cell
in gerrit build:
deps = [
'@jgit//org.eclipse.jgit:jgit',
],
This simplifies JGit Buck build implementation, as we wouldn't need to
proxy all artifacts referenced from gerrit build from the root build
file. And this would fix all remaining issues.
This approach make gerrit build slightly more verbose. JGit upgrade
process would need to touch 4 files instead of only one. But given that
the Gerrit/JGit development integration is important feature, we would
like to support (as this integration attempt shows: [3]) in our build
toolchain, this overhead is justified.
With this change, the root build file in JGit project can be stripped:
[4].
[1] https://git.eclipse.org/r/61938
[2] https://git.eclipse.org/r/66547
[3] https://gerrit-review.googlesource.com/61892
[4] https://git.eclipse.org/r/66562
Change-Id: I2d278f80d0fedc4c5e9943804873f57145877dfe
Consume JGit as first third party library from its own cell. Normally
the cell is defined as lib/jgit directory. It can be easily replaced
with CLI:
buck build --config repositories.jgit=path/to/dev/jgit gerrit
or tweaking the .buckconfig:
[repositories]
jgit = path/to/dev/jgit
The former approach is sufficient to build and run the test from the
CLI, the latter is needed to generate eclipse project.
To isolate the JGit rules in its own cell some refactoring was needed.
JGit patch for GWT module was moved to gerrit-patch-jgit project, and
some symlinks were needed for maven machinery to work. include_defs()
doesn't work for now across cell boundaries, and native `buck fetch`
feature still has some limitations: [1]. Moreover, excluding paths,
unsigning JARs and license linking should be re-implemented on top
of it.
[1] https://github.com/facebook/buck/issues/602
Test Plan:
Normal gerrit build and the build with hijacked JGit cell should work
in both standalone (gerrit.war) and Eclipse environment. Note, that
to test --config repositories.jgit=path/to/dev/jgit use case, the most
recent JGit tree must be used, that contains Buck driven build
implementation.
Change-Id: I39f2d5d75bbac88804406d6242b5e714f4916926
gerrit-server:server transitively depends on the dropwizard library
and thus it's included in the plugin API. Exporting it allow plugins
to depend on it in tree build, without explicitly mentioning it in
provided_deps.
Change-Id: Idcda84cd845330e3efb575c9fe9d508d584d7bff
We don't really need to set the version for RC releases since we
don't typically deploy them to Maven.
Change-Id: Ic3b5df303689145ff88b51b7035defcaa3fa65b2
Split the current gerrit-acceptance-tests in two parts:
* framework + some needed deps, that is exposed as additional plugin
artifact
* rest of the gerrit-acceptance-test project
To implement the split and not to pull in too many dependencies, some
refactoring was needed. Particularly, gerrit-server:testutil depends
on gerrit-server:server, that depends on almost everything. Similar
problem was with gerrit-pgm:pgm, that is needed for AbstractDaemonTest
to work. Split the rules in gerrit-pgm to break transitive dependency
chain. We shouldn't ship artifacts twice, in plugin-api and in
acceptance-framework.
This change also partially reverts Ie9e63de622, where
//gerrit-acceptance-tests:lib with all its transitive dependencies was
included in plugin-api artifact.
Expose gerrit-acceptance-framework as new plugin artifact. This allows
us to support unit tests in plugins in three different build modes:
* Buck in tree build mode
* Buck standalone build mode
* Maven build
To install gerrit-acceptance-framework locally, the following command
is used:
buck build api_install
To deploy gerrit-acceptance-framework to Maven Central, the following
command is used:
buck build api_deploy
To support unit tests in tree build mode, the following Buck variable
is exposed: GERRIT_TESTS and can be used, e.g.:
java_test(
name = 'cookbook_tests',
srcs = glob(['src/test/java/**/*IT.java']),
labels = ['cookbook-plugin'],
source_under_test = [':cookbook-plugin__plugin'],
deps = GERRIT_PLUGIN_API + GERRIT_TESTS + [
':cookbook-plugin__plugin',
],
)
To support unit tests in standalone build mode, acceptance-framework
maven jar is defined in lib/gerrit/BUCK file:
maven_jar(
name = 'acceptance-framework',
id = 'com.google.gerrit:gerrit-acceptance-framework:' + VER,
license = 'Apache2.0',
attach_source = False,
repository = REPO,
)
bucklets/gerrit_plugin.bucklet is extended with the same variable
that points to the new maven_jar artifact, so that the same Buck
java_test() rule can be used in both modes.
Test plan:
1. run tests in gerrit tree
2. apply corresponding change to cookbook-plugin and run tests in
gerrit tree mode
3. apply corresponding change to bucklets, and run tests for
cookbook-plugin in standalone build mode
Change-Id: I4cadf6616de36ca24712f8b07d282b7a50911105
gerrit-server transitively depends on //lib/joda:joda-time, and
thus this dependency was always included in gerrit-plugin-api.
Exporting it allows in tree plugin to also depend on it, without
mentioning it as explicit dependency, which would unnecessarily
complicate standalone build implementation.
This change allows us to simplify Buck in tree and standalone build
implementation for websession-flatfile plugin.
Change-Id: Idfb2401424cd13676a8bb7918278cbcac672dc87
gerrit-server transitively depends on lib:velocity, and thus this
dependency was always included in gerrit-plugin-api. Exporting it
allows in tree plugin to also depends on it, without mentioning it
as explicit dependency, which would unnecessarily complicate
standalone build implementation.
This change can be used to simplify Buck in tree and standalone
build implementations for its-* plugins.
Change-Id: Ide02bc5d3eae841ae88675981b1d7d01df4fed66
Create PluginDaemonTest to load plugin jars in the Gerrit test server
before running the plugin acceptance tests. Plugin IT classes shall
extend PluginDaemonTest in order to enable this functionality.
Make beforeTest in AbstractDaemonTest protected so it can be overridden
by hereby PluginDaemonTest.
Add UNIT_TEST_GERRIT_SITE constant to InMemoryTestingDatabaseModule so
it can be reused by PluginDaemonTest.
Package acceptance tests into plugin-api jar.
Support standalone and non-standalone (all) buck modes for tested
plugin. Running IT tests using a maven pom is *not* supported by this
change.
Support ability for such plugin IT tests to set plugin config string in
gerrit config.
Change-Id: Ie9e63de622708272f4f5e154a80a55a97d8ff77c
commons-io is no longer used in core Gerrit. Remove the dependency and
stop exporting it in the plugin API.
Also update the replication plugin to the latest revision:
- Bundle commons-io since gerrit core no longer provides it
Change-Id: I6bcf6ec6134039de7d8f9c1670167a0318510745