Thanks Erik! Just thought I missed a tool which I should know :)
On Mon, Dec 12, 2016 at 5:14 PM, Erik Joelsson <[email protected]> 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 <[email protected]> >> 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 > >
