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

Volker Simonis volker.simonis at gmail.com
Mon Dec 12 16:20:49 UTC 2016

Thanks Erik!

Just thought I missed a tool which I should know :)

On Mon, Dec 12, 2016 at 5:14 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> Hello Volker,
> Jib is an Oracle internal tool, but just like with JPRT, we need to put
> configuration elements for Jib in the open source repositories for
> convenience.
> /Erik
> On 2016-12-12 17:08, Volker Simonis wrote:
>> Hi,
>> just out of interest - is Jib an Oracle-internal tool or is it freely
>> available.
>> In the case it is freely available, can you please post some links to
>> locations from wher ewe can get more information about JIB?
>> Thanks,
>> Volker
>> On Fri, Dec 9, 2016 at 3:55 PM, Erik Joelsson <erik.joelsson at oracle.com>
>> wrote:
>>> Hello
>>> 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)
>>> Fixed.
>>>> 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.
>>> /Erik

More information about the build-dev mailing list