Initial CL for talking to the WebAPK server to generate WebAPK

chrome/browser/android/webapk/DEPS

Index: chrome/browser/android/webapk/DEPS
diff --git a/chrome/browser/android/webapk/DEPS b/chrome/browser/android/webapk/DEPS
new file mode 100644
index 0000000000000000000000000000000000000000..d7ddd9cf46defbc427dc76e3761234706559dd5b
--- /dev/null
+++ b/chrome/browser/android/webapk/DEPS
@@ -0,0 +1,6 @@
+specific_include_rules = {
+  "webapk_builder_unittest\.cc": [
+    "+content/renderer/manifest/manifest_parser.h",

[Yaron, 2016/07/13 00:24:01]

does this need to be moved to content/public or are there examples of unittests
which reach into content (I'm unsure)

[Yaron, 2016/07/19 17:31:13]

bump.

looking at the test, I don't think it's testing the right thing.
content::ManifestParser isn't even going to really parse the manifest (the
server will) and is orthogonal to your functionality.

[pkotwicz, 2016/07/20 05:13:41]

You are right using content/renderer/manifest/manifest_parser.h in the unit test
is wrong. The spirit of the test is correct. The server API is defined in terms
of the W3C Web Manifest spec. Testing WebApkBuilder::OrientationToString()
against ManifestParser is valid. Perhaps I should introduce ManifestUtil in
content/public/manifest_util.h which converts between
blink::WebScreenOrientationLockType <-> std::string. What do you think?

[Yaron, 2016/07/20 13:13:50]

That would be fine with me. Another option would be to move the enum conversion
code down to content (with a public accessor) and test it there. It's nice in
that it localizes it with the relevant code as opposed to the mapping being in a
consumer and it's not dependent on our specific feature.

+  ]
+}
+