Download doclava when building for Android and use to build cronet Javadocs

[Cronet] Use doclava to build Cronet Javadocs

During "gclient runhooks", download doclava from Google Storage when building for Android.
Switching to doclava allows using the @hide tag instead of
the @deprecated tag which leads to build warnings.
Doclava does not have a nodeprecated option so deprecated
types are @hide'd.

BUG=539519
Committed: https://crrev.com/62bd31bc7e6d863e87e167e4a6701b64cf584a54
Cr-Commit-Position: refs/heads/master@{#386077}

Committed: https://crrev.com/657cf55ea4d2e793438148116c2bdd959a7b85bf
Cr-Commit-Position: refs/heads/master@{#387656}

[pauljensen, 2016-02-12 15:33:58]

Description was changed from

==========
[WIP] Download doclava when building for Android and use to build cronet
Javadocs

BUG=539519
==========

to

==========
[Cronet] Use doclava to build Cronet Javadocs

During "gclient runhooks", download doclava from Google Storage when building
for Android.
Switching to doclava allows using the @hide tag instead of
the @deprecated tag which leads to build warnings.
Doclava does not have a nodeprecated option so deprecated
types are @hide'd.

BUG=539519
==========

[pauljensen, 2016-02-12 15:33:58]

pauljensen@chromium.org changed reviewers:
+ xunjieli@chromium.org

[pauljensen, 2016-02-12 15:34:09]

Helen, PTAL.

[xunjieli, 2016-02-12 19:14:43]

Awesome work. Great that we are finally having the support. I have a few
questions below just to make sure I understand.

https://codereview.chromium.org/1557233003/diff/80001/build/android/download_...
File build/android/download_doclava.py (right):

https://codereview.chromium.org/1557233003/diff/80001/build/android/download_...
build/android/download_doclava.py:2: # Copyright 2014 The Chromium Authors. All
rights reserved.
nit: 2016

https://codereview.chromium.org/1557233003/diff/80001/components/cronet/andro...
File components/cronet/android/api/build.xml (right):

https://codereview.chromium.org/1557233003/diff/80001/components/cronet/andro...
components/cronet/android/api/build.xml:24: <param
name="../../../../buildtools/android/doclava/current.txt"/>
What are these federation params?

https://codereview.chromium.org/1557233003/diff/80001/components/cronet/andro...
File
components/cronet/android/api/src/org/chromium/net/NetworkQualityRttListener.java
(right):

https://codereview.chromium.org/1557233003/diff/80001/components/cronet/andro...
components/cronet/android/api/src/org/chromium/net/NetworkQualityRttListener.java:12:
* {@hide} as it's a prototype.
Why do we use brackets around @hide?

[pauljensen, 2016-02-12 19:20:59]

https://codereview.chromium.org/1557233003/diff/80001/build/android/download_...
File build/android/download_doclava.py (right):

https://codereview.chromium.org/1557233003/diff/80001/build/android/download_...
build/android/download_doclava.py:2: # Copyright 2014 The Chromium Authors. All
rights reserved.
On 2016/02/12 19:14:43, xunjieli wrote:
> nit: 2016

Done.

https://codereview.chromium.org/1557233003/diff/80001/components/cronet/andro...
File components/cronet/android/api/build.xml (right):

https://codereview.chromium.org/1557233003/diff/80001/components/cronet/andro...
components/cronet/android/api/build.xml:24: <param
name="../../../../buildtools/android/doclava/current.txt"/>
On 2016/02/12 19:14:43, xunjieli wrote:
> What are these federation params?

This is how doclava does the "linkoffline" behavior.  This is how it knows to
generate links to https://developer.android.com for things like java.lang.String
and android.content.Context.

https://codereview.chromium.org/1557233003/diff/80001/components/cronet/andro...
File
components/cronet/android/api/src/org/chromium/net/NetworkQualityRttListener.java
(right):

https://codereview.chromium.org/1557233003/diff/80001/components/cronet/andro...
components/cronet/android/api/src/org/chromium/net/NetworkQualityRttListener.java:12:
* {@hide} as it's a prototype.
On 2016/02/12 19:14:43, xunjieli wrote:
> Why do we use brackets around @hide?

In a class comment it didn't seem to work correctly without the curly braces.

[xunjieli, 2016-02-12 19:58:38]

Tried patching your CL, but it failed at the gclient runhooks step with the
error same as in the android_cronet_tester.

[pauljensen, 2016-02-12 20:23:39]

On 2016/02/12 19:58:38, xunjieli wrote:
> Tried patching your CL, but it failed at the gclient runhooks step with the
> error same as in the android_cronet_tester.

Patch into buildtools: https://codereview.chromium.org/1554123002/

[xunjieli, 2016-02-12 20:50:08]

On 2016/02/12 20:23:39, pauljensen wrote:
> On 2016/02/12 19:58:38, xunjieli wrote:
> > Tried patching your CL, but it failed at the gclient runhooks step with the
> > error same as in the android_cronet_tester.
> 
> Patch into buildtools: https://codereview.chromium.org/1554123002/

Sorry, I haven't followed the status closely. Should we land this other patch
first?

[pauljensen, 2016-02-12 21:08:10]

On 2016/02/12 20:50:08, xunjieli wrote:
> On 2016/02/12 20:23:39, pauljensen wrote:
> > On 2016/02/12 19:58:38, xunjieli wrote:
> > > Tried patching your CL, but it failed at the gclient runhooks step with
the
> > > error same as in the android_cronet_tester.
> > 
> > Patch into buildtools: https://codereview.chromium.org/1554123002/
> 
> Sorry, I haven't followed the status closely. Should we land this other patch
> first?

Ya, but I wanted to get this one under review first as it's much bigger.

[pauljensen, 2016-02-15 01:41:34]

I should mention that the doclava generated HTML doesn't look very pleasant.  If
you apply a "template" to it, it gets much easier on the eyes.  Android includes
several different templates, see
http://androidxref.com/6.0.1_r10/xref/build/tools/droiddoc/, but most of them
are clearly branded with big Android logos and other stuff that isn't applicable
to Cronet.  Anyhow, I think for now we can live with ugly javadocs, and if we
have some time we can apply a template to make it more pleasant to look at.

[xunjieli, 2016-02-16 15:38:03]

On 2016/02/15 01:41:34, pauljensen wrote:
> I should mention that the doclava generated HTML doesn't look very pleasant. 
If
> you apply a "template" to it, it gets much easier on the eyes.  Android
includes
> several different templates, see
> http://androidxref.com/6.0.1_r10/xref/build/tools/droiddoc/, but most of them
> are clearly branded with big Android logos and other stuff that isn't
applicable
> to Cronet.  Anyhow, I think for now we can live with ugly javadocs, and if we
> have some time we can apply a template to make it more pleasant to look at.

that sounds good to me as long as the content is okay. I am trying to understand
how this works, and I have a couple of questions.
Your other CL lists the SHA1 hash to pull from AOSP branch. How is the google
storage bucket organized? Why is it you can specify a hash, and it can pull from
the AOSP branch. I thought your crbug comment mentioned that the one in google
storage bucket isn't the same as the one on AOSP branch. Has this been changed?
What does jsilver do? is the jsilver packaged together with doclava? Is
README.chromium in the storage bucket and not in the source tree? What is
current.txt? Do we still need the Android API XML file?

If it's easier, I can ask you the questions in person.

[pauljensen, 2016-02-16 18:37:40]

On 2016/02/16 15:38:03, xunjieli wrote:
> On 2016/02/15 01:41:34, pauljensen wrote:
> > I should mention that the doclava generated HTML doesn't look very pleasant.

> If
> > you apply a "template" to it, it gets much easier on the eyes.  Android
> includes
> > several different templates, see
> > http://androidxref.com/6.0.1_r10/xref/build/tools/droiddoc/, but most of
them
> > are clearly branded with big Android logos and other stuff that isn't
> applicable
> > to Cronet.  Anyhow, I think for now we can live with ugly javadocs, and if
we
> > have some time we can apply a template to make it more pleasant to look at.
> 
> that sounds good to me as long as the content is okay. I am trying to
understand
> how this works, and I have a couple of questions.
> Your other CL lists the SHA1 hash to pull from AOSP branch. How is the google
> storage bucket organized? Why is it you can specify a hash, and it can pull
from
> the AOSP branch. I thought your crbug comment mentioned that the one in google
> storage bucket isn't the same as the one on AOSP branch. Has this been
changed?
> What does jsilver do? is the jsilver packaged together with doclava? Is
> README.chromium in the storage bucket and not in the source tree? What is
> current.txt? Do we still need the Android API XML file?
> 
> If it's easier, I can ask you the questions in person.

I put together the Google Storage bucket cintents myself and uploaded it.  The
hash is just the hash of the archive I uploaded.  The README.chromium contains
the exact commands I used to assemble the bucket contents, including checking
out AOSP and where that current.txt came from.  The doclava in AOSP, besides
being the only doclava that seemed to work well, also can use files like
current.txt instead of the Android API XML, which is good because Android
switched from generating XML to txt for their API long ago.

[xunjieli, 2016-02-16 23:12:03]

On 2016/02/16 18:37:40, pauljensen wrote:
> On 2016/02/16 15:38:03, xunjieli wrote:
> > On 2016/02/15 01:41:34, pauljensen wrote:
> > > I should mention that the doclava generated HTML doesn't look very
pleasant.
> 
> > If
> > > you apply a "template" to it, it gets much easier on the eyes.  Android
> > includes
> > > several different templates, see
> > > http://androidxref.com/6.0.1_r10/xref/build/tools/droiddoc/, but most of
> them
> > > are clearly branded with big Android logos and other stuff that isn't
> > applicable
> > > to Cronet.  Anyhow, I think for now we can live with ugly javadocs, and if
> we
> > > have some time we can apply a template to make it more pleasant to look
at.
> > 
> > that sounds good to me as long as the content is okay. I am trying to
> understand
> > how this works, and I have a couple of questions.
> > Your other CL lists the SHA1 hash to pull from AOSP branch. How is the
google
> > storage bucket organized? Why is it you can specify a hash, and it can pull
> from
> > the AOSP branch. I thought your crbug comment mentioned that the one in
google
> > storage bucket isn't the same as the one on AOSP branch. Has this been
> changed?
> > What does jsilver do? is the jsilver packaged together with doclava? Is
> > README.chromium in the storage bucket and not in the source tree? What is
> > current.txt? Do we still need the Android API XML file?
> > 
> > If it's easier, I can ask you the questions in person.
> 
> I put together the Google Storage bucket cintents myself and uploaded it.  The
> hash is just the hash of the archive I uploaded.  The README.chromium contains
> the exact commands I used to assemble the bucket contents, including checking
> out AOSP and where that current.txt came from.  The doclava in AOSP, besides
> being the only doclava that seemed to work well, also can use files like
> current.txt instead of the Android API XML, which is good because Android
> switched from generating XML to txt for their API long ago.

I see. Thanks for explaining. That makes so much more sense now. What does
jsilver do?

[pauljensen, 2016-02-17 03:24:43]

On 2016/02/16 23:12:03, xunjieli wrote:
> On 2016/02/16 18:37:40, pauljensen wrote:
> > On 2016/02/16 15:38:03, xunjieli wrote:
> > > On 2016/02/15 01:41:34, pauljensen wrote:
> > > > I should mention that the doclava generated HTML doesn't look very
> pleasant.
> > 
> > > If
> > > > you apply a "template" to it, it gets much easier on the eyes.  Android
> > > includes
> > > > several different templates, see
> > > > http://androidxref.com/6.0.1_r10/xref/build/tools/droiddoc/, but most of
> > them
> > > > are clearly branded with big Android logos and other stuff that isn't
> > > applicable
> > > > to Cronet.  Anyhow, I think for now we can live with ugly javadocs, and
if
> > we
> > > > have some time we can apply a template to make it more pleasant to look
> at.
> > > 
> > > that sounds good to me as long as the content is okay. I am trying to
> > understand
> > > how this works, and I have a couple of questions.
> > > Your other CL lists the SHA1 hash to pull from AOSP branch. How is the
> google
> > > storage bucket organized? Why is it you can specify a hash, and it can
pull
> > from
> > > the AOSP branch. I thought your crbug comment mentioned that the one in
> google
> > > storage bucket isn't the same as the one on AOSP branch. Has this been
> > changed?
> > > What does jsilver do? is the jsilver packaged together with doclava? Is
> > > README.chromium in the storage bucket and not in the source tree? What is
> > > current.txt? Do we still need the Android API XML file?
> > > 
> > > If it's easier, I can ask you the questions in person.
> > 
> > I put together the Google Storage bucket cintents myself and uploaded it. 
The
> > hash is just the hash of the archive I uploaded.  The README.chromium
contains
> > the exact commands I used to assemble the bucket contents, including
checking
> > out AOSP and where that current.txt came from.  The doclava in AOSP, besides
> > being the only doclava that seemed to work well, also can use files like
> > current.txt instead of the Android API XML, which is good because Android
> > switched from generating XML to txt for their API long ago.
> 
> I see. Thanks for explaining. That makes so much more sense now. What does
> jsilver do?

I'm not entirely sure, there used to be a page describing it here:
  https://code.google.com/p/jsilver
But I can't seem to open it anymore.
Anyhow, doclava seems to require it, and it's also included in AOSP, so I built
it along with doclava.

[xunjieli, 2016-02-17 14:44:47]

On 2016/02/17 03:24:43, pauljensen wrote:
> On 2016/02/16 23:12:03, xunjieli wrote:
> > On 2016/02/16 18:37:40, pauljensen wrote:
> > > On 2016/02/16 15:38:03, xunjieli wrote:
> > > > On 2016/02/15 01:41:34, pauljensen wrote:
> > > > > I should mention that the doclava generated HTML doesn't look very
> > pleasant.
> > > 
> > > > If
> > > > > you apply a "template" to it, it gets much easier on the eyes. 
Android
> > > > includes
> > > > > several different templates, see
> > > > > http://androidxref.com/6.0.1_r10/xref/build/tools/droiddoc/, but most
of
> > > them
> > > > > are clearly branded with big Android logos and other stuff that isn't
> > > > applicable
> > > > > to Cronet.  Anyhow, I think for now we can live with ugly javadocs,
and
> if
> > > we
> > > > > have some time we can apply a template to make it more pleasant to
look
> > at.
> > > > 
> > > > that sounds good to me as long as the content is okay. I am trying to
> > > understand
> > > > how this works, and I have a couple of questions.
> > > > Your other CL lists the SHA1 hash to pull from AOSP branch. How is the
> > google
> > > > storage bucket organized? Why is it you can specify a hash, and it can
> pull
> > > from
> > > > the AOSP branch. I thought your crbug comment mentioned that the one in
> > google
> > > > storage bucket isn't the same as the one on AOSP branch. Has this been
> > > changed?
> > > > What does jsilver do? is the jsilver packaged together with doclava? Is
> > > > README.chromium in the storage bucket and not in the source tree? What
is
> > > > current.txt? Do we still need the Android API XML file?
> > > > 
> > > > If it's easier, I can ask you the questions in person.
> > > 
> > > I put together the Google Storage bucket cintents myself and uploaded it. 
> The
> > > hash is just the hash of the archive I uploaded.  The README.chromium
> contains
> > > the exact commands I used to assemble the bucket contents, including
> checking
> > > out AOSP and where that current.txt came from.  The doclava in AOSP,
besides
> > > being the only doclava that seemed to work well, also can use files like
> > > current.txt instead of the Android API XML, which is good because Android
> > > switched from generating XML to txt for their API long ago.
> > 
> > I see. Thanks for explaining. That makes so much more sense now. What does
> > jsilver do?
> 
> I'm not entirely sure, there used to be a page describing it here:
>   https://code.google.com/p/jsilver
> But I can't seem to open it anymore.
> Anyhow, doclava seems to require it, and it's also included in AOSP, so I
built
> it along with doclava.

I see. Lgtm!

[pauljensen, 2016-02-25 15:40:01]

pauljensen@chromium.org changed reviewers:
+ mikecase@chromium.org

[pauljensen, 2016-02-25 15:40:02]

Mike, PTAL @ build/android/download_doclava.py

[pauljensen, 2016-02-27 08:21:24]

On 2016/02/25 15:40:02, pauljensen (OOO until Mar 16) wrote:
> Mike, PTAL @ build/android/download_doclava.py

Mike, friendly ping.

[mikecase (-- gone --), 2016-02-29 16:35:15]

https://codereview.chromium.org/1557233003/diff/100001/build/android/download...
File build/android/download_doclava.py (right):

https://codereview.chromium.org/1557233003/diff/100001/build/android/download...
build/android/download_doclava.py:15: if 'OS=android' not in
os.environ.get('GYP_DEFINES', ''):
Not sure if this approach will work after everything is switched over
to GN. Do you know if cronet is switching over to GN soon?

[pauljensen, 2016-02-29 18:48:10]

https://codereview.chromium.org/1557233003/diff/100001/build/android/download...
File build/android/download_doclava.py (right):

https://codereview.chromium.org/1557233003/diff/100001/build/android/download...
build/android/download_doclava.py:15: if 'OS=android' not in
os.environ.get('GYP_DEFINES', ''):
On 2016/02/29 16:35:15, mikecase wrote:
> Not sure if this approach will work after everything is switched over
> to GN. Do you know if cronet is switching over to GN soon?

I don't know when Cronet is switching to GN; I think right now the official
Android buildbots use GYP so we can't switch.  I should note that there are
several download scripts that use GYP_DEFINES:

https://code.google.com/p/chromium/codesearch#search/&q=GYP_DEFINES%20file:%5...

Is there an alternative GN way of determining target build OS for scripts
launched from DEPS from "gclient runhooks"?

[mikecase (-- gone --), 2016-02-29 19:32:47]

mikecase@chromium.org changed reviewers:
+ agrieve@chromium.org

[mikecase (-- gone --), 2016-02-29 19:32:47]

+agrieve

He's done lots with GN and should know how to determine if the OS=android when
calling
a script from DEPS.

[agrieve, 2016-03-01 01:18:45]

https://codereview.chromium.org/1557233003/diff/100001/build/android/download...
File build/android/download_doclava.py (right):

https://codereview.chromium.org/1557233003/diff/100001/build/android/download...
build/android/download_doclava.py:15: if 'OS=android' not in
os.environ.get('GYP_DEFINES', ''):
On 2016/02/29 18:48:10, pauljensen (OOO until Mar 16) wrote:
> On 2016/02/29 16:35:15, mikecase wrote:
> > Not sure if this approach will work after everything is switched over
> > to GN. Do you know if cronet is switching over to GN soon?
> 
> I don't know when Cronet is switching to GN; I think right now the official
> Android buildbots use GYP so we can't switch.  I should note that there are
> several download scripts that use GYP_DEFINES:
> 
>
https://code.google.com/p/chromium/codesearch#search/&q=GYP_DEFINES%20file:%5...
> 
> Is there an alternative GN way of determining target build OS for scripts
> launched from DEPS from "gclient runhooks"?

There's some relevant discussion in this bug:
https://bugs.chromium.org/p/chromium/issues/detail?id=564869

I think checking for the existence of platform-specific directories is still the
best work-around for now.

[pauljensen, 2016-03-17 14:05:10]

Mike, PTAL, thank you!

https://codereview.chromium.org/1557233003/diff/100001/build/android/download...
File build/android/download_doclava.py (right):

https://codereview.chromium.org/1557233003/diff/100001/build/android/download...
build/android/download_doclava.py:15: if 'OS=android' not in
os.environ.get('GYP_DEFINES', ''):
On 2016/03/01 01:18:45, agrieve wrote:
> On 2016/02/29 18:48:10, pauljensen (OOO until Mar 16) wrote:
> > On 2016/02/29 16:35:15, mikecase wrote:
> > > Not sure if this approach will work after everything is switched over
> > > to GN. Do you know if cronet is switching over to GN soon?
> > 
> > I don't know when Cronet is switching to GN; I think right now the official
> > Android buildbots use GYP so we can't switch.  I should note that there are
> > several download scripts that use GYP_DEFINES:
> > 
> >
>
https://code.google.com/p/chromium/codesearch#search/&q=GYP_DEFINES%20file:%5...
> > 
> > Is there an alternative GN way of determining target build OS for scripts
> > launched from DEPS from "gclient runhooks"?
> 
> There's some relevant discussion in this bug:
> https://bugs.chromium.org/p/chromium/issues/detail?id=564869
> 
> I think checking for the existence of platform-specific directories is still
the
> best work-around for now.

Done.

[pauljensen, 2016-03-21 18:18:15]

Mike, friendly ping.

[mikecase (-- gone --), 2016-03-21 18:29:29]

lgtm

[pauljensen, 2016-03-23 11:22:06]

The CQ bit was checked by pauljensen@chromium.org

[pauljensen, 2016-03-23 11:22:07]

The patchset sent to the CQ was uploaded after l-g-t-m from
xunjieli@chromium.org
Link to the patchset: https://codereview.chromium.org/1557233003/#ps120001
(title: "switch from GYP_DEFINES to path existence")

[commit-bot: I haz the power, 2016-03-23 11:22:17]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1557233003/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1557233003/120001

[commit-bot: I haz the power, 2016-03-23 11:23:46]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-23 11:23:47]

Try jobs failed on following builders:
  linux_chromium_compile_dbg_32_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  ios_dbg_simulator_gn on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...)
  ios_dbg_simulator_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...)

[pauljensen, 2016-03-23 12:14:29]

The CQ bit was checked by pauljensen@chromium.org

[pauljensen, 2016-03-23 12:14:29]

The patchset sent to the CQ was uploaded after l-g-t-m from
mikecase@chromium.org, xunjieli@chromium.org
Link to the patchset: https://codereview.chromium.org/1557233003/#ps140001
(title: "sync")

[commit-bot: I haz the power, 2016-03-23 12:14:51]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1557233003/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1557233003/140001

[commit-bot: I haz the power, 2016-03-23 12:30:46]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-23 12:30:47]

Try jobs failed on following builders:
  win8_chromium_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_ng/...)

[pauljensen, 2016-03-23 14:11:00]

agrieve,mikecase: It appears the win8_chromium_ng and win_chromium_rel_ng bots
have third_party/android_tools directories.  Should this be fixed (i.e. by
removing those directories?) or should I make my script skip downloading on
Windows?

[pauljensen, 2016-03-28 13:29:19]

On 2016/03/23 14:11:00, pauljensen wrote:
> agrieve,mikecase: It appears the win8_chromium_ng and win_chromium_rel_ng bots
> have third_party/android_tools directories.  Should this be fixed (i.e. by
> removing those directories?) or should I make my script skip downloading on
> Windows?

Mikecase, Agrieve: Friendly ping.

[pauljensen, 2016-03-30 11:50:25]

On 2016/03/28 13:29:19, pauljensen wrote:
> On 2016/03/23 14:11:00, pauljensen wrote:
> > agrieve,mikecase: It appears the win8_chromium_ng and win_chromium_rel_ng
bots
> > have third_party/android_tools directories.  Should this be fixed (i.e. by
> > removing those directories?) or should I make my script skip downloading on
> > Windows?
> 
> Mikecase, Agrieve: Friendly ping.

Mikecase, Agrieve: Ping.

[pauljensen, 2016-04-04 13:21:41]

On 2016/03/30 11:50:25, pauljensen wrote:
> On 2016/03/28 13:29:19, pauljensen wrote:
> > On 2016/03/23 14:11:00, pauljensen wrote:
> > > agrieve,mikecase: It appears the win8_chromium_ng and win_chromium_rel_ng
> bots
> > > have third_party/android_tools directories.  Should this be fixed (i.e. by
> > > removing those directories?) or should I make my script skip downloading
on
> > > Windows?
> > 
> > Mikecase, Agrieve: Friendly ping.
> 
> Mikecase, Agrieve: Ping.

Mikecase, Agrieve: Ping!

[pauljensen, 2016-04-05 17:50:38]

pauljensen@chromium.org changed reviewers:
+ jbudorick@chromium.org

[pauljensen, 2016-04-05 17:50:39]

+jbudorick as I haven't got a response in 2 weeks from mikecase or agrieve.

John, do you know the best way to determine if building for Android in a DEPS
script?  I originally used GYP_DEFINES (like some other scripts) but was told
that isn't the preferred way (what with the GN conversion).  I switched to using
the existence of third_party/android_tools but it appears at least a couple of
the Windows bots have that directory present.  Do you have any ideas how this
should be done?  Should those windows bots be fixed to not have android_tools
present?

[agrieve, 2016-04-05 18:10:31]

On 2016/04/05 17:50:39, pauljensen wrote:
> +jbudorick as I haven't got a response in 2 weeks from mikecase or agrieve.
> 
> John, do you know the best way to determine if building for Android in a DEPS
> script?  I originally used GYP_DEFINES (like some other scripts) but was told
> that isn't the preferred way (what with the GN conversion).  I switched to
using
> the existence of third_party/android_tools but it appears at least a couple of
> the Windows bots have that directory present.  Do you have any ideas how this
> should be done?  Should those windows bots be fixed to not have android_tools
> present?

Wow, somehow I never saw any of your previous updates! (sorry)! Just kicked off
another windows tryjob since the log for the other one is now gone.

[jbudorick, 2016-04-05 18:20:37]

On 2016/04/05 17:50:39, pauljensen wrote:
> +jbudorick as I haven't got a response in 2 weeks from mikecase or agrieve.

:(

> 
> John, do you know the best way to determine if building for Android in a DEPS
> script?  I originally used GYP_DEFINES (like some other scripts) but was told
> that isn't the preferred way (what with the GN conversion).  I switched to
using
> the existence of third_party/android_tools but it appears at least a couple of
> the Windows bots have that directory present.  Do you have any ideas how this
> should be done?  Should those windows bots be fixed to not have android_tools
> present?

I'd agree that using GYP_DEFINES is the wrong way. I don't know of a method
that's preferable to the existence of third_party/android_tools/; that's what we
use for the other android-specific hook that I know of. I'm surprised to hear
that the Windows bots have that directory; they shouldn't, and yes, they should
be fixed to not have them.

[pauljensen, 2016-04-05 18:49:36]

So both re-runs today of the windows bots got past the runhooks step... :/ 
weird.  Should I try CQing this and perhaps give the sheriffs a heads up that
this might turn some bots red if they have those directories present
inadvertently?

[agrieve, 2016-04-05 18:52:05]

On 2016/04/05 18:49:36, pauljensen wrote:
> So both re-runs today of the windows bots got past the runhooks step... :/ 
> weird.  Should I try CQing this and perhaps give the sheriffs a heads up that
> this might turn some bots red if they have those directories present
> inadvertently?

sgtm

[pauljensen, 2016-04-06 16:10:28]

The CQ bit was checked by pauljensen@chromium.org

[commit-bot: I haz the power, 2016-04-06 16:10:50]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1557233003/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1557233003/140001

[commit-bot: I haz the power, 2016-04-06 16:23:22]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-04-06 16:23:24]

Try jobs failed on following builders:
  win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[pauljensen, 2016-04-06 16:30:05]

agrieve, mikecase, jbudorick: so it looks like this windows bot has a
third_party/android_tools directory.  How should we go about removing this?  I
think it may be the case that various random windows bots have this directory...
 Ideas: 1. put in some DEPS script that deletes this directory on windows. 2.
have my script assume windows is not building for android.

On 2016/04/06 16:23:24, commit-bot: I haz the power wrote:
> Try jobs failed on following builders:
>   win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_FAILED,
>
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[jbudorick, 2016-04-06 16:33:16]

On 2016/04/06 16:30:05, pauljensen wrote:
> agrieve, mikecase, jbudorick: so it looks like this windows bot has a
> third_party/android_tools directory.  How should we go about removing this?  I
> think it may be the case that various random windows bots have this
directory...
>  Ideas: 1. put in some DEPS script that deletes this directory on windows. 2.
> have my script assume windows is not building for android.

While (2) is a safe assumption for us to make, I'd be interested in figuring out
how these windows bots got this directory. It's supposed to be an Android-only
repository brought in by DEPS...

> 
> On 2016/04/06 16:23:24, commit-bot: I haz the power wrote:
> > Try jobs failed on following builders:
> >   win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_FAILED,
> >
>
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[agrieve, 2016-04-06 17:16:32]

On 2016/04/06 16:33:16, jbudorick wrote:
> On 2016/04/06 16:30:05, pauljensen wrote:
> > agrieve, mikecase, jbudorick: so it looks like this windows bot has a
> > third_party/android_tools directory.  How should we go about removing this? 
I
> > think it may be the case that various random windows bots have this
> directory...
> >  Ideas: 1. put in some DEPS script that deletes this directory on windows.
2.
> > have my script assume windows is not building for android.
> 
> While (2) is a safe assumption for us to make, I'd be interested in figuring
out
> how these windows bots got this directory. It's supposed to be an Android-only
> repository brought in by DEPS...
> 
> > 
> > On 2016/04/06 16:23:24, commit-bot: I haz the power wrote:
> > > Try jobs failed on following builders:
> > >   win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_FAILED,
> > >
> >
>
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

Logged into the bot, and it indeed has all the android directories.
Suspect the reason is that the gclient has: target_os_only=False
Note that it also doesn't set a target_os.

https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_com...

[agrieve, 2016-04-06 17:20:21]

On 2016/04/06 17:16:32, agrieve wrote:
> On 2016/04/06 16:33:16, jbudorick wrote:
> > On 2016/04/06 16:30:05, pauljensen wrote:
> > > agrieve, mikecase, jbudorick: so it looks like this windows bot has a
> > > third_party/android_tools directory.  How should we go about removing
this? 
> I
> > > think it may be the case that various random windows bots have this
> > directory...
> > >  Ideas: 1. put in some DEPS script that deletes this directory on windows.
> 2.
> > > have my script assume windows is not building for android.
> > 
> > While (2) is a safe assumption for us to make, I'd be interested in figuring
> out
> > how these windows bots got this directory. It's supposed to be an
Android-only
> > repository brought in by DEPS...
> > 
> > > 
> > > On 2016/04/06 16:23:24, commit-bot: I haz the power wrote:
> > > > Try jobs failed on following builders:
> > > >   win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_FAILED,
> > > >
> > >
> >
>
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)
> 
> Logged into the bot, and it indeed has all the android directories.
> Suspect the reason is that the gclient has: target_os_only=False
> Note that it also doesn't set a target_os.
> 
>
https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_com...

John - do you know what's setting this entry in the .gclient? I don't see a
--specs flag to bot_update, so maybe there's another thing that creates the
.gclient file?

[jbudorick, 2016-04-06 17:24:09]

On 2016/04/06 17:20:21, agrieve wrote:
> On 2016/04/06 17:16:32, agrieve wrote:
> > On 2016/04/06 16:33:16, jbudorick wrote:
> > > On 2016/04/06 16:30:05, pauljensen wrote:
> > > > agrieve, mikecase, jbudorick: so it looks like this windows bot has a
> > > > third_party/android_tools directory.  How should we go about removing
> this? 
> > I
> > > > think it may be the case that various random windows bots have this
> > > directory...
> > > >  Ideas: 1. put in some DEPS script that deletes this directory on
windows.
> > 2.
> > > > have my script assume windows is not building for android.
> > > 
> > > While (2) is a safe assumption for us to make, I'd be interested in
figuring
> > out
> > > how these windows bots got this directory. It's supposed to be an
> Android-only
> > > repository brought in by DEPS...
> > > 
> > > > 
> > > > On 2016/04/06 16:23:24, commit-bot: I haz the power wrote:
> > > > > Try jobs failed on following builders:
> > > > >   win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_FAILED,
> > > > >
> > > >
> > >
> >
>
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)
> > 
> > Logged into the bot, and it indeed has all the android directories.
> > Suspect the reason is that the gclient has: target_os_only=False
> > Note that it also doesn't set a target_os.
> > 
> >
>
https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_com...
> 
> John - do you know what's setting this entry in the .gclient? I don't see a
> --specs flag to bot_update, so maybe there's another thing that creates the
> .gclient file?

I have no idea. I didn't even know that was an option. I'm going to assume it
was intentional, though, which means we either shouldn't use the existence of
third_party/android_tools as a way to check for platform or that we should make
download_doclava work and/or fail gracefully on non-Android checkouts.

[jbudorick, 2016-04-06 17:24:48]

https://codereview.chromium.org/1557233003/diff/140001/build/android/download...
File build/android/download_doclava.py (right):

https://codereview.chromium.org/1557233003/diff/140001/build/android/download...
build/android/download_doclava.py:29: '-s',
'src/buildtools/android/doclava.tar.gz.sha1'])
from the windows failure log, it looks like this could work if you did

  os.path.join('src', 'buildtools', 'android', 'doclava.tar.gz.sha1')

here.

[pauljensen, 2016-04-06 18:42:34]

https://codereview.chromium.org/1557233003/diff/140001/build/android/download...
File build/android/download_doclava.py (right):

https://codereview.chromium.org/1557233003/diff/140001/build/android/download...
build/android/download_doclava.py:29: '-s',
'src/buildtools/android/doclava.tar.gz.sha1'])
On 2016/04/06 17:24:47, jbudorick wrote:
> from the windows failure log, it looks like this could work if you did
> 
>   os.path.join('src', 'buildtools', 'android', 'doclava.tar.gz.sha1')
> 
> here.

Done.

[jbudorick, 2016-04-06 18:55:13]

build/ lgtm

[pauljensen, 2016-04-07 00:20:47]

The CQ bit was checked by pauljensen@chromium.org

[pauljensen, 2016-04-07 00:20:48]

The patchset sent to the CQ was uploaded after l-g-t-m from
mikecase@chromium.org, xunjieli@chromium.org
Link to the patchset: https://codereview.chromium.org/1557233003/#ps160001
(title: "use os.path.join")

[commit-bot: I haz the power, 2016-04-07 00:21:22]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1557233003/160001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1557233003/160001

[commit-bot: I haz the power, 2016-04-07 00:30:25]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-04-07 00:30:27]

Try jobs failed on following builders:
  linux_blink_oilpan_rel on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_blink_oil...)
  win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)
  win_chromium_x64_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[pauljensen, 2016-04-07 19:01:49]

Hmm two of the windows bots failed with the error below.  I have no idea what's
wrong with these bot's checkouts...  I'm not sure what file they're complaining
about, and all files should be present.

________ running 'E:\b\depot_tools\python276_bin\python.exe
src/build/android/download_doclava.py' in 'E:\b\build\slave\win\build'
Traceback (most recent call last):
  File "src/build/android/download_doclava.py", line 34, in <module>
    sys.exit(main())
  File "src/build/android/download_doclava.py", line 30, in main
    os.path.join('src', 'buildtools', 'android', 'doclava.tar.gz.sha1')])
  File "E:\b\depot_tools\python276_bin\lib\subprocess.py", line 535, in
check_call
    retcode = call(*popenargs, **kwargs)
  File "E:\b\depot_tools\python276_bin\lib\subprocess.py", line 522, in call
    return Popen(*popenargs, **kwargs).wait()
  File "E:\b\depot_tools\python276_bin\lib\subprocess.py", line 709, in __init__
    errread, errwrite)
  File "E:\b\depot_tools\python276_bin\lib\subprocess.py", line 957, in
_execute_child
    startupinfo)
WindowsError: [Error 2] The system cannot find the file specified
Error: Command 'E:\\b\\depot_tools\\python276_bin\\python.exe
src/build/android/download_doclava.py' returned non-zero exit status 1 in
E:\b\build\slave\win\build
step returned non-zero exit code: 2

[agrieve, 2016-04-07 19:42:44]

On 2016/04/07 19:01:49, pauljensen wrote:
> Hmm two of the windows bots failed with the error below.  I have no idea
what's
> wrong with these bot's checkouts...  I'm not sure what file they're
complaining
> about, and all files should be present.
> 
> ________ running 'E:\b\depot_tools\python276_bin\python.exe
> src/build/android/download_doclava.py' in 'E:\b\build\slave\win\build'
> Traceback (most recent call last):
>   File "src/build/android/download_doclava.py", line 34, in <module>
>     sys.exit(main())
>   File "src/build/android/download_doclava.py", line 30, in main
>     os.path.join('src', 'buildtools', 'android', 'doclava.tar.gz.sha1')])
>   File "E:\b\depot_tools\python276_bin\lib\subprocess.py", line 535, in
> check_call
>     retcode = call(*popenargs, **kwargs)
>   File "E:\b\depot_tools\python276_bin\lib\subprocess.py", line 522, in call
>     return Popen(*popenargs, **kwargs).wait()
>   File "E:\b\depot_tools\python276_bin\lib\subprocess.py", line 709, in
__init__
>     errread, errwrite)
>   File "E:\b\depot_tools\python276_bin\lib\subprocess.py", line 957, in
> _execute_child
>     startupinfo)
> WindowsError: [Error 2] The system cannot find the file specified
> Error: Command 'E:\\b\\depot_tools\\python276_bin\\python.exe
> src/build/android/download_doclava.py' returned non-zero exit status 1 in
> E:\b\build\slave\win\build
> step returned non-zero exit code: 2


I'd guess this means that on those lovely machines, that depot_tools in not in
the PATH.

I think at this point you should just go with the if not os.platform == 'win32'
check.

[pauljensen, 2016-04-08 12:03:11]

On 2016/04/07 19:42:44, agrieve wrote:
> On 2016/04/07 19:01:49, pauljensen wrote:
> > Hmm two of the windows bots failed with the error below.  I have no idea
> what's
> > wrong with these bot's checkouts...  I'm not sure what file they're
> complaining
> > about, and all files should be present.
> > 
> > ________ running 'E:\b\depot_tools\python276_bin\python.exe
> > src/build/android/download_doclava.py' in 'E:\b\build\slave\win\build'
> > Traceback (most recent call last):
> >   File "src/build/android/download_doclava.py", line 34, in <module>
> >     sys.exit(main())
> >   File "src/build/android/download_doclava.py", line 30, in main
> >     os.path.join('src', 'buildtools', 'android', 'doclava.tar.gz.sha1')])
> >   File "E:\b\depot_tools\python276_bin\lib\subprocess.py", line 535, in
> > check_call
> >     retcode = call(*popenargs, **kwargs)
> >   File "E:\b\depot_tools\python276_bin\lib\subprocess.py", line 522, in call
> >     return Popen(*popenargs, **kwargs).wait()
> >   File "E:\b\depot_tools\python276_bin\lib\subprocess.py", line 709, in
> __init__
> >     errread, errwrite)
> >   File "E:\b\depot_tools\python276_bin\lib\subprocess.py", line 957, in
> > _execute_child
> >     startupinfo)
> > WindowsError: [Error 2] The system cannot find the file specified
> > Error: Command 'E:\\b\\depot_tools\\python276_bin\\python.exe
> > src/build/android/download_doclava.py' returned non-zero exit status 1 in
> > E:\b\build\slave\win\build
> > step returned non-zero exit code: 2
> 
> 
> I'd guess this means that on those lovely machines, that depot_tools in not in
> the PATH.
> 
> I think at this point you should just go with the if not os.platform ==
'win32'
> check.

Done.

[agrieve, 2016-04-08 13:29:21]

On 2016/04/08 12:03:11, pauljensen wrote:
> On 2016/04/07 19:42:44, agrieve wrote:
> > On 2016/04/07 19:01:49, pauljensen wrote:
> > > Hmm two of the windows bots failed with the error below.  I have no idea
> > what's
> > > wrong with these bot's checkouts...  I'm not sure what file they're
> > complaining
> > > about, and all files should be present.
> > > 
> > > ________ running 'E:\b\depot_tools\python276_bin\python.exe
> > > src/build/android/download_doclava.py' in 'E:\b\build\slave\win\build'
> > > Traceback (most recent call last):
> > >   File "src/build/android/download_doclava.py", line 34, in <module>
> > >     sys.exit(main())
> > >   File "src/build/android/download_doclava.py", line 30, in main
> > >     os.path.join('src', 'buildtools', 'android', 'doclava.tar.gz.sha1')])
> > >   File "E:\b\depot_tools\python276_bin\lib\subprocess.py", line 535, in
> > > check_call
> > >     retcode = call(*popenargs, **kwargs)
> > >   File "E:\b\depot_tools\python276_bin\lib\subprocess.py", line 522, in
call
> > >     return Popen(*popenargs, **kwargs).wait()
> > >   File "E:\b\depot_tools\python276_bin\lib\subprocess.py", line 709, in
> > __init__
> > >     errread, errwrite)
> > >   File "E:\b\depot_tools\python276_bin\lib\subprocess.py", line 957, in
> > > _execute_child
> > >     startupinfo)
> > > WindowsError: [Error 2] The system cannot find the file specified
> > > Error: Command 'E:\\b\\depot_tools\\python276_bin\\python.exe
> > > src/build/android/download_doclava.py' returned non-zero exit status 1 in
> > > E:\b\build\slave\win\build
> > > step returned non-zero exit code: 2
> > 
> > 
> > I'd guess this means that on those lovely machines, that depot_tools in not
in
> > the PATH.
> > 
> > I think at this point you should just go with the if not os.platform ==
> 'win32'
> > check.
> 
> Done.

lgtm

[pauljensen, 2016-04-08 13:54:29]

The CQ bit was checked by pauljensen@chromium.org

[pauljensen, 2016-04-08 13:54:29]

The patchset sent to the CQ was uploaded after l-g-t-m from
mikecase@chromium.org, jbudorick@chromium.org, xunjieli@chromium.org
Link to the patchset: https://codereview.chromium.org/1557233003/#ps180001
(title: "avoid downloading on windows")

[commit-bot: I haz the power, 2016-04-08 13:54:50]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1557233003/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1557233003/180001

[commit-bot: I haz the power, 2016-04-08 15:11:26]

Description was changed from

==========
[Cronet] Use doclava to build Cronet Javadocs

During "gclient runhooks", download doclava from Google Storage when building
for Android.
Switching to doclava allows using the @hide tag instead of
the @deprecated tag which leads to build warnings.
Doclava does not have a nodeprecated option so deprecated
types are @hide'd.

BUG=539519
==========

to

==========
[Cronet] Use doclava to build Cronet Javadocs

During "gclient runhooks", download doclava from Google Storage when building
for Android.
Switching to doclava allows using the @hide tag instead of
the @deprecated tag which leads to build warnings.
Doclava does not have a nodeprecated option so deprecated
types are @hide'd.

BUG=539519
==========

[commit-bot: I haz the power, 2016-04-08 15:11:28]

Committed patchset #10 (id:180001)

[commit-bot: I haz the power, 2016-04-08 15:12:51]

Description was changed from

==========
[Cronet] Use doclava to build Cronet Javadocs

During "gclient runhooks", download doclava from Google Storage when building
for Android.
Switching to doclava allows using the @hide tag instead of
the @deprecated tag which leads to build warnings.
Doclava does not have a nodeprecated option so deprecated
types are @hide'd.

BUG=539519
==========

to

==========
[Cronet] Use doclava to build Cronet Javadocs

During "gclient runhooks", download doclava from Google Storage when building
for Android.
Switching to doclava allows using the @hide tag instead of
the @deprecated tag which leads to build warnings.
Doclava does not have a nodeprecated option so deprecated
types are @hide'd.

BUG=539519

Committed: https://crrev.com/62bd31bc7e6d863e87e167e4a6701b64cf584a54
Cr-Commit-Position: refs/heads/master@{#386077}
==========

[commit-bot: I haz the power, 2016-04-08 15:12:52]

Patchset 10 (id:??) landed as
https://crrev.com/62bd31bc7e6d863e87e167e4a6701b64cf584a54
Cr-Commit-Position: refs/heads/master@{#386077}

[pauljensen, 2016-04-08 15:46:09]

A revert of this CL (patchset #10 id:180001) has been created in
https://codereview.chromium.org/1868203002/ by pauljensen@chromium.org.

The reason for reverting is: Passes once and then subsequent builds fail with
"javadoc: error - Cannot find doclet class com.google.doclava.Doclava".
My guess is download_from_google_storage is somehow not extracting the next
time, and some script is clearing the extracted directory but not the downloaded
archive.

BUG=601800.

[pauljensen, 2016-04-08 19:15:47]

Description was changed from

==========
[Cronet] Use doclava to build Cronet Javadocs

During "gclient runhooks", download doclava from Google Storage when building
for Android.
Switching to doclava allows using the @hide tag instead of
the @deprecated tag which leads to build warnings.
Doclava does not have a nodeprecated option so deprecated
types are @hide'd.

BUG=539519

Committed: https://crrev.com/62bd31bc7e6d863e87e167e4a6701b64cf584a54
Cr-Commit-Position: refs/heads/master@{#386077}
==========

to

==========
[Cronet] Use doclava to build Cronet Javadocs

During "gclient runhooks", download doclava from Google Storage when building
for Android.
Switching to doclava allows using the @hide tag instead of
the @deprecated tag which leads to build warnings.
Doclava does not have a nodeprecated option so deprecated
types are @hide'd.

BUG=539519

Committed: https://crrev.com/62bd31bc7e6d863e87e167e4a6701b64cf584a54
Cr-Commit-Position: refs/heads/master@{#386077}
==========

[pauljensen, 2016-04-08 19:18:14]

I modified the download script to perform the tar extraction step separately
from the download step, this should address the bot failures that resulted
previously. PTAL.

[agrieve, 2016-04-11 17:12:57]

Don't know why it wasn't working, but wonder if the fix go in
download_from_google_storage?

https://codereview.chromium.org/1557233003/diff/200001/build/android/download...
File build/android/download_doclava.py (right):

https://codereview.chromium.org/1557233003/diff/200001/build/android/download...
build/android/download_doclava.py:62: '-s', sha1file])
You should add a comment saying why --extract doesn't work.

https://codereview.chromium.org/1557233003/diff/200001/build/android/download...
build/android/download_doclava.py:72: subprocess.check_call(['tar', 'axf',
os.path.abspath(tarball)], cwd=outdir)
Probably better to use Python's tarfile module for this rather than
sub-shelling. (Should be just a couple of lines)

[pauljensen, 2016-04-11 17:38:51]

On 2016/04/11 17:12:57, agrieve wrote:
> Don't know why it wasn't working, but wonder if the fix go in
> download_from_google_storage?

It looked like download_from_google_storage was working properly, and it was
properly extracted the first time it downloaded the file.  The problem looked
like some part of the bot update process deleted the resulting extracted
directory.

[agrieve, 2016-04-11 18:25:21]

On 2016/04/11 17:38:51, pauljensen wrote:
> On 2016/04/11 17:12:57, agrieve wrote:
> > Don't know why it wasn't working, but wonder if the fix go in
> > download_from_google_storage?
> 
> It looked like download_from_google_storage was working properly, and it was
> properly extracted the first time it downloaded the file.  The problem looked
> like some part of the bot update process deleted the resulting extracted
> directory.

Hmm, might be the real fix is to add the directory to .gitignore? If I patch in
your cl & run it, I get:

$ cd src/buildtools/android; git status

# HEAD detached at a2082ca
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       doclava.tar.gz
#       doclava.tar.gz.stamp
#       doclava/
#

I can't think of why extracting manually would end up differently from having
the download script do it.

[pauljensen, 2016-04-12 12:14:39]

Good catch agrieve@, I've reverted this CL back to Patch Set 10, and uploaded
https://codereview.chromium.org/1883563002/ to fix gitignore.

[agrieve, 2016-04-12 13:55:56]

On 2016/04/12 12:14:39, pauljensen wrote:
> Good catch agrieve@, I've reverted this CL back to Patch Set 10, and uploaded
> https://codereview.chromium.org/1883563002/ to fix gitignore.

lgtm to try again then once the .gitignore is in.

[pauljensen, 2016-04-15 17:15:49]

The CQ bit was checked by pauljensen@chromium.org

[pauljensen, 2016-04-15 17:15:49]

The patchset sent to the CQ was uploaded after l-g-t-m from
mikecase@chromium.org, jbudorick@chromium.org, xunjieli@chromium.org
Link to the patchset: https://codereview.chromium.org/1557233003/#ps220001
(title: "revert back to Patch Set 10")

[commit-bot: I haz the power, 2016-04-15 17:16:21]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1557233003/220001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1557233003/220001

[commit-bot: I haz the power, 2016-04-15 18:36:16]

Description was changed from

==========
[Cronet] Use doclava to build Cronet Javadocs

During "gclient runhooks", download doclava from Google Storage when building
for Android.
Switching to doclava allows using the @hide tag instead of
the @deprecated tag which leads to build warnings.
Doclava does not have a nodeprecated option so deprecated
types are @hide'd.

BUG=539519

Committed: https://crrev.com/62bd31bc7e6d863e87e167e4a6701b64cf584a54
Cr-Commit-Position: refs/heads/master@{#386077}
==========

to

==========
[Cronet] Use doclava to build Cronet Javadocs

During "gclient runhooks", download doclava from Google Storage when building
for Android.
Switching to doclava allows using the @hide tag instead of
the @deprecated tag which leads to build warnings.
Doclava does not have a nodeprecated option so deprecated
types are @hide'd.

BUG=539519

Committed: https://crrev.com/62bd31bc7e6d863e87e167e4a6701b64cf584a54
Cr-Commit-Position: refs/heads/master@{#386077}
==========

[commit-bot: I haz the power, 2016-04-15 18:36:19]

Committed patchset #12 (id:220001)

[commit-bot: I haz the power, 2016-04-15 18:37:51]

Description was changed from

==========
[Cronet] Use doclava to build Cronet Javadocs

During "gclient runhooks", download doclava from Google Storage when building
for Android.
Switching to doclava allows using the @hide tag instead of
the @deprecated tag which leads to build warnings.
Doclava does not have a nodeprecated option so deprecated
types are @hide'd.

BUG=539519

Committed: https://crrev.com/62bd31bc7e6d863e87e167e4a6701b64cf584a54
Cr-Commit-Position: refs/heads/master@{#386077}
==========

to

==========
[Cronet] Use doclava to build Cronet Javadocs

During "gclient runhooks", download doclava from Google Storage when building
for Android.
Switching to doclava allows using the @hide tag instead of
the @deprecated tag which leads to build warnings.
Doclava does not have a nodeprecated option so deprecated
types are @hide'd.

BUG=539519

Committed: https://crrev.com/62bd31bc7e6d863e87e167e4a6701b64cf584a54
Cr-Commit-Position: refs/heads/master@{#386077}

Committed: https://crrev.com/657cf55ea4d2e793438148116c2bdd959a7b85bf
Cr-Commit-Position: refs/heads/master@{#387656}
==========

[commit-bot: I haz the power, 2016-04-15 18:37:53]

Patchset 12 (id:??) landed as
https://crrev.com/657cf55ea4d2e793438148116c2bdd959a7b85bf
Cr-Commit-Position: refs/heads/master@{#387656}