RFR: JDK-8170741: Enable uploading of built artifacts through Jib
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Thu Dec 8 13:19:32 UTC 2016
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
> 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
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?
More information about the build-dev