Hi David, Thanks for the tip, the build server now uses the openZip task and the bundles appear to be fine when unzipped into a Java installation.
Updated the instructions and it also now creates a build from 9-dev/rt. http://108.61.191.178/ The intention is still to move this over to Adoption Group's CloudBees but for now this helps IoT ARM JDKs to get OpenJFX support. Cheers, Chris On Wed, March 11, 2015 16:36, David Hill wrote: > On 3/9/15, 5:00 AM, Chris Newland wrote: > >> Hi all, >> >> >> A quick update on this: >> >> >> There are a small number of wrinkles before we get OpenJFX building on >> the Adoption group's CloudBees system so I've put together a >> Debian-based VPS >> server that is producing nightly OpenJFX builds for Linux amd64 and >> armv6hf. >> >> It updates fromhttp://hg.openjdk.java.net/openjfx/8u-dev/rt and pulls >> the latest crosslibs dependencies before building so it's the bleeding >> edge of the OpenJFX codebase. > Chris, > I forgot to blast this out to the group: > > > gradle openZip > > which is part of gradle zip -or- > gradle all at least in the open builds. > > This target was added a month or so ago, and I just fixed something in > in, that meant it was not showing up in openZip properly. > > This target builds a bundle in > ./builds/[platform-]bundles/javafx-sdk-overlay.zip > > > The contents include jfxrt.jar which has been filtered in a similar > fashion to the JFX product, removing some stuff that is not appropriate > to a given platform. (Yes that means Monocle on non-arm platforms). The > logic is pretty straight forward - ie Windows classes don't show up on a > non-windows platform. > > The resulting bundle *should* be able to be deployed by just unpacking it > over a JDK, which is intended to simplify matters. > > Dave > > > > -- > David Hill<david.h...@oracle.com> > Java Embedded Development > > > "A man's feet should be planted in his country, but his eyes should > survey the world." -- George Santayana (1863 - 1952) > > >
