| commit | 3f0d3b68a273250b1bf70c278d0700a1ed30058c | [log] [tgz] |
|---|---|---|
| author | Jingwen Chen <jingwen@google.com> | Thu Sep 22 17:46:49 2016 +0000 |
| committer | Laszlo Csomor <laszlocsomor@google.com> | Fri Sep 23 08:15:38 2016 +0000 |
| tree | a42fbe38ccb308930238fea911cef9b1fe2b2370 | |
| parent | 296ffbde796f00c7a493330089085f9be1442f0b [diff] |
Implementation of maven_jar rule in Skylark.
**Experimental**
This is an initial implementation of the maven_jar rule in Skylark, targeted at
the FRs in issue #1410.
Implemented a wrapper around the maven binary to pull dependencies from
remote repositories into a directory under {output_base}/external.
Attributes `name`, `artifact`, `repository`, `sha1` have been implemented,
but not `server`.
Caveat: this rule assumes that the Maven dependency is installed in the
system. Hence, the maven_skylark_test integration tests are tagged with
"manual" and commented out because the Bazel CI isn't configured with
the Maven binary yet.
Added a serve_not_found helper for 404 response tests.
Usage:
```
load("@bazel_tools//tools/build_defs/repo:maven_rules.bzl", "maven_jar")
maven_jar(
name = "com_google_guava_guava",
artifact = "com.google.guava:guava:18.0",
sha1 = "cce0823396aa693798f8882e64213b1772032b09",
repository = "http://uk.maven.org/maven2",
)
```
With regards to server, there are some limitations with retrieving a
maven_server's attribute at Loading Phase without the use of hacky macros
(issue #1704), and even if macros are used, the maven_server is not treated as
an actual dependency by maven_jar. There is a test (`test_unimplemented_server_attr`)
to ensure that the error message to shown to users if they use the server
attribute with this rule.
--
Change-Id: I167f9d13835c30be971928b4cc60167a8e396893
Reviewed-on: https://bazel-review.googlesource.com/c/5770
MOS_MIGRATED_REVID=133971809
{Fast, Correct} - Choose two
Bazel is a build tool that builds code quickly and reliably. It is used to build the majority of Google‘s software, and thus it has been designed to handle build problems present in Google’s development environment, including:
A massive, shared code repository, in which all software is built from source. Bazel has been built for speed, using both caching and parallelism to achieve this. Bazel is critical to Google's ability to continue to scale its software development practices as the company grows.
An emphasis on automated testing and releases. Bazel has been built for correctness and reproducibility, meaning that a build performed on a continuous build machine or in a release pipeline will generate bitwise-identical outputs to those generated on a developer's machine.
Language and platform diversity. Bazel's architecture is general enough to support many different programming languages within Google, and can be used to build both client and server software targeting multiple architectures from the same underlying codebase.
Find more background about Bazel in our FAQ.