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

Erik Joelsson erik.joelsson at oracle.com
Fri Dec 9 14:55:58 UTC 2016


New webrev: http://cr.openjdk.java.net/~erikj/8170741/webrev.02/

On 2016-12-08 14:19, Magnus Ihse Bursie wrote:
> 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?
Good point, moved.


More information about the build-dev mailing list