FYI: Build system rewrite in Ant

[James Laskey]

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 <martijnverburg at 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.katleman at 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.bursie at 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
>>