I may have been misled, but I thought Ant was replaced by a non-deterministic build system called Termight.
Sent from my iPhone > On Apr 1, 2015, at 6:59 AM, Martijn Verburg <martijnverb...@gmail.com> wrote: > > I'm personally willing to provide a ANT to MAVEN conversion tool which will > allow for a more verbose an rdable build system. It will also ensure that > dependencies are always downloaded at all times ensuring network pipes are > kept clean. > > Cheers, > Martijn > > On 1 April 2015 at 10:21, David Katleman (Oracle) <david.katle...@oracle.com >> wrote: > >> +1 >> >> Please say were going to use the extension that predict build failures >> before they occur and provides an automated root cause analysis. I believe >> is called Ant predictive recursive interpreter language with Forensic >> object oriented linguistic syntax. >> >> >>>> On Apr 1, 2015, at 1:33 AM, Magnus Ihse Bursie < >>> magnus.ihse.bur...@oracle.com> wrote: >>> >>> The build system currently uses make to build OpenJDK. This is a >> technology that has been around for decades, and in places this legacy >> clearly shows. >>> >>> An alternative build tool, Ant, is based on cutting-edge technology. >> Compared to the native GNU Make, Ant is based on Java™ technology, which >> makes portability issues a thing of the past. Ant is also directed using >> modern XML systems, with well-defined tags, compared to the aged and >> idiosyncratic Makefile syntax. >>> >>> The Build Team has therefore decided to rewrite the current build system >> from scratch in Ant. The old Makefiles will be put in maintenance mode >> while the new Ant scripts are being developed. To facilitate a speedy >> switch, all new build enhancements must be expressed in Ant logic, starting >> today. No modifications in the old Makefiles will be accepted by the Build >> Team. >>> >>> To increase the robustness of the code base, the new build system will >> automatically check the integrity of all source code files before >> compilation. Each source file therefore must be accompanied by a Integrity >> Manifest (.Ingeg_Manif.xml). For instance, the file Object.java would have >> an Object.java.Integ_Manif.xml. This is a simple xml file, describing the >> purpose of the source code file, and a log of mercurial changeset id:s. An >> example file could looks like this: >>> >>> <manifest xmlns="http://openjdk.java.net/ns/manifest/integrity/1";> >>> <type>net.java.openjdk.build.ant.manifest.integrity</type> >>> <artifacts> >>> <artifact> >>> <source-code-descriptor> >>> <filename>Object.java</filename> >>> <description>Class Object is the root of the class >> hierarchy.</description> >>> </source-code-descriptor> >>> </artifact> >>> </artifacts> >>> <integrity> >>> <revision-control> >>> <committed-change> >>> <changeid>541a8cef4e0d</changeid> >> <revision-control-system>mercurial</revision-control-system> >>> </committed-change> >>> <committed-change> >>> <changeid>458adf31ad5b</changeid> >> <revision-control-system>mercurial</revision-control-system> >>> </committed-change> >>> <committed-change> >>> <changeid>0846eddb56d5</changeid> >> <revision-control-system>mercurial</revision-control-system> >>> </committed-change> >>> </revision-control> >>> </integrity> >>> </manifest> >>> >>> Each time a new version of the file is committed to the mercurial repo, >> the developer just has to add a new committed-change stanza to the block in >> the .Ingeg_Manif.xml file. Since the changeset ID is not known before hand, >> the Integrity Manifest file must be updated in a subsequent commit. >>> >>> But fear not! To assist developers in preserving the integrity of the >> source files, an addition to jcheck has been developed. If the subsequent >> commit does not properly describe the previous changeset ID, the original >> changeset will be automatically reverted, so no untracked changes will be >> stored permanently in the revision control system. >>> >>> Finally, to fully utilize the promise of portability that the Ant and >> Java™ technology brings, platforms with portability issues will be removed >> from the supported platform matrix. Currently, this only includes >> non-POSIX-compliant operating systems, since these have been known to cause >> various platform issues in the build system. The only known >> non-POSIX-compliant OS that the OpenJDK build system currently supports is >> the Windows OS family, so this reduction in support is hopefully not too >> burdensome. >>> >>> These changes will take immediate effect of today, April 1 2015. >>> >>> That's all for today, folks! :-) >>> >>> /Magnus >>
