Use white flat svg instead of old java duke icon

[ajkannan]

Here's a screenshot:

[jgeewax]

LGTM

[ajkannan]

Question on process: this logo change on gcloud-java's landing page only go into effect next time somebody on gcloud-java runs maven's site-deploy (since Travis times out building the website at the moment, we have to do it manually. This is going to change soon). Since regenerating and deploying the entire website+docs takes ~2 hrs and seems a bit excessive for just a logo update, do you think I should push those changes directly to gh-pages for the time being? And if so, should that go via PR, or just directly? cc/ @dhermes

[dhermes]

😮

[aozarov]

I am fine with a PR for changing the icon though I do wonder if it is desired to copy all resources for every site version... Alternative would be to have some of the resources (such as icons) to be checked into gh-pages (e.g. /icons/) and change the relevant links/references to use full path (e.g. /icons/icon-lang-java-duke-white.svg).

Also, slightly related, I think we should cleanup gh-pages and remove the old content and instead add a redirect to latest directly at the root of gh-pages so http://googlecloudplatform.github.io/gcloud-java/ will take us to the right place).

[jgeewax]

Pushing all new stuff shouldn't be a 2 hour operation.... Can we make work towards fixing that issue? We're talking about a minute max for Python, Node, Ruby, etc, and they cover far more APIs.... I'm going to guess if we make this faster, the problem goes away. (This is eerily reminding me of our old 200mb repository problem...)

[ajkannan]

Alright, I'll work on that now.

[ajkannan]

@aozarov, just to make sure we're on the same page, I'm planning to:

1. Remove all the 0.0.4 files in the root directory of gh-pages
2. Move site/0.0.6/ --> 0.0.6/ and site/0.0.7/ --> 0.0.7/ (the extra "site" folder seems unnecessary)
3. Move the redirect to the latest site version to the home directory
4. Move some of the resources (css/img/etc) a folder in gh-pages and stop copying those over each time we release the site
5. We will run mvn site only when we up the version, but we can make changes (i.e. the logo change) manually in between version releases.
6. Deploy the site via github push (not maven)

Let me know if that all sounds right. Since these are a lot of changes, I'll split them into two PRs

[aozarov]

That sounds right.

I assume the 2 hours (for me it does not take that long) includes the push time?
How much time does it take for maven stage to run locally on your machine? For me it is much longer than a minute (especially after we started using modules) but still in the order of minutes. I doubt we
can improve on that (and should focus on the push time - #140) but no harm in creating an issue for it as well...

[ajkannan]

Yeah, the 2 hours was a push time for my last deployment. When I run site and then stage, it takes my machine ~4 minutes. Hopefully travis will work at least that fast so we won't hit the timeouts.