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

[Erik Joelsson]

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