FYI: Build system rewrite in Ant

[Martijn Verburg]

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
>