FYI: Build system rewrite in Ant
James Laskey
james.laskey at oracle.com
Wed Apr 1 10:18:14 UTC 2015
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
>>
More information about the jdk9-dev
mailing list