RFR: JDK-8170741: Enable uploading of built artifacts through Jib

[Magnus Ihse Bursie]

On 2016-12-05 16:35, Erik Joelsson wrote:
> For a while now, Oracle engineers have been able to configure builds 
> of JDK 9 with binary dependencies automatically downloaded from an 
> artifact storage, using Jib. Since then, Jib has been enhanced to also 
> support publishing build artifacts produced by the build into the same 
> storage. Such artifacts can subsequently be used as dependencies for 
> other build targets.
>
> With this change, the Jib profiles configuration in JDK 9 are updated 
> to leverage this new functionality in Jib. By doing this, we are able 
> to express and define all deliverables from the build in the source 
> code. We are also able to define possible workflows where one build 
> step requires input from another.
>
> This change attempts to describe all artifacts currently built and 
> stored by RE, with a few known exceptions that will be adjusted in 
> followup fixes.
>
> With this change, there is a fair bit of refactoring in the 
> jib-profiles.js file(s). The old designe resulted in a fair bit of 
> duplicated configure arguments and it was hard to control what 
> settings got duplicated in variants of profiles, such as *-debug. I 
> believe the new patterns are more flexible without sacrificing 
> readability. I have manually inspected the generated configure lines 
> for all relevant profiles and compared before and after the change to 
> make sure no regressions are introduced by this.
>
> I moved more of the default version numbers into the version-numbers 
> file so that they can be read from jib-profiles.js.
>
> In langtools/test/Makefile, I made it possible to override the 
> TEST_OUTPUT_DIR, like it is currently possible for the other test 
> makefiles.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8170741
>
> Webrev: http://cr.openjdk.java.net/~erikj/8170741/webrev.01/

Looks good to me overall, but I do not like the massive amount of code 
duplication in profilesArtifacts. These could, and should, be generated 
from some suitable input (like name of os and cpu in the resulting 
bundle, etc)

The new print-config.js tool, is it used somewhere, or is it just 
provided as a development tool for adhoc use? Is common/conf really the 
proper place for it, and not common/bin?

/Magnus

>
> /Erik
>