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

[Volker Simonis]

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
>
>