commit | b5099530084deb61fcb9e60314579dd0daed79b5 | [log] [tgz] |
---|---|---|
author | David Ostrovsky <david@ostrovsky.org> | Sat May 06 06:35:48 2017 +0200 |
committer | Kasper Nilsson <kaspern@google.com> | Tue May 09 11:14:21 2017 -0700 |
tree | d1690fc68ccc93a01de0100b5715d84434d03495 | |
parent | 452a5c6fa8d8c150147972bc8031776c4a4d474c [diff] |
maven_jar compatibility to rules_closure#java_import_external 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] https://github.com/bazelbuild/rules_closure/commit/a47cc063d39b3958f31b4c5a992741020fd9ee3e [2] https://github.com/bazelbuild/rules_closure/issues/200 Change-Id: I31e6b863e43adaa1f983a8a9da1675f02cb803f8
Gerrit is a code review and project management tool for Git based projects.
Gerrit makes reviews easier by showing changes in a side-by-side display, and allowing inline comments to be added by any reviewer.
Gerrit simplifies Git based project maintainership by permitting any authorized user to submit changes to the master Git repository, rather than requiring all approved changes to be merged in by hand by the project maintainer.
For information about how to install and use Gerrit, refer to the documentation.
Our canonical Git repository is located on googlesource.com. There is a mirror of the repository on Github.
Please report bugs on the issue tracker.
Gerrit is the work of hundreds of contributors. We appreciate your help!
Please read the contribution guidelines.
Note that we do not accept Pull Requests via the Github mirror.
The IRC channel on freenode is #gerrit. An archive is available at: echelog.com.
The Developer Mailing list is repo-discuss on Google Groups.
Gerrit is provided under the Apache License 2.0.
Install Bazel and run the following:
git clone --recursive https://gerrit.googlesource.com/gerrit cd gerrit && bazel build release
The instruction how to configure GerritForge/BinTray repositories is here
On Debian/Ubuntu run:
apt-get update & apt-get install gerrit=<version>-<release>
NOTE: release is a counter that starts with 1 and indicates the number of packages that have been released with the same version of the software.
On CentOS/RedHat run:
yum clean all && yum install gerrit-<version>[-<release>]
On Fedora run:
dnf clean all && dnf install gerrit-<version>[-<release>]
Docker images of Gerrit are available on DockerHub
To run a CentOS 7 based Gerrit image:
docker run -p 8080:8080 gerritforge/gerrit-centos7[:version]
To run a Ubuntu 15.04 based Gerrit image:
docker run -p 8080:8080 gerritforge/gerrit-ubuntu15.04[:version]
NOTE: release is optional. Last released package of the version is installed if the release number is omitted.