JavaFX 8u40 EA for Android
joeri at lodgon.com
Wed Nov 26 21:12:47 UTC 2014
the location to both the android sdk and the dalvik sdk should currently
already be provided by the developer by specifying it in the
About the need for a gradle installation, can't we use the gradle wrapper
for this to specify which gradle version we should depend on. The gradle
wrapper was built for this purpose: to download and install the correct
gradle version if it couldn't be found on the system.
Op 26-nov.-2014 21:37 schreef "Danno Ferrin" <danno.ferrin at oracle.com>:
> On Nov 26, 2014, at 12:39 PM, Johan Vos <johan at lodgon.com> wrote:
> > Hi Danno,
> > Is it possible to execute a gradle script as part of the (external)
> Possible, yes. I don't think it is a good idea. The bundler would need
> to depend on a gradle runtime and stand a build dir up and call it. Which
> would make maven and nested gradle builds a mess.
> If the build is deeply integrated to the way gradle does things, it bodes
> poorly for a stand alone packager. Of couse it seems to me that android is
> deeply embedding itself with gradle so this may be unavoidable.
> > We have a rather simple build.gradle file that uses the android plugin
> and that has almost no metadata (if your application uses external
> libraries, they have to be added in the dependency section). I added the
> structure of the simple HelloAndroid demo in attachment.
> > The reason I want to use this gradle script is that it leverages the
> android plugin which does all the work (convert to dex, build packages
> etc). We used to do this with an ant build, but that is much more complex.
> That's the point of the bundler. Move it from point A to point B and
> hiding all of the crazy inner details.
> > Before I write down the details, it would be nice to hear if this is
> possible with the current hooks in the packager:
> > 1. create a build.gradle file based on a template and on some metadata
> (the application jar and external dependencies)
> > 2. also create a AndroidManifest.xml file based on a template and some
> more metadata (the name of the application, optionally the minimal android
> version that is required, an icon,...)
> > 3. download the android SDK and JavaFX-Dalvik SDK in case the user
> doesn't have this yet. The locations of those 2 files are used by the
> build.gradle file in step 1
> > 4. run the gradle command to execute the gradle script. There are
> different commands for creating packages (debug/release) and/or for
> installing them on a device (to test).
> > If this approach is not feasable, I will try to break down the
> functionality of the Android plugin into a number of steps.
> It is possible, we basically do this for all the bundlers, set up some
> files and the hand off to InnoSetup, or WiX, or rpm, or dpkg, or mac tools.
> So that would increase the build reqs to require that Android SDK is
> installed, the gradle plugin is installed, and gradle is installed
> somewhere. Are there default/recommended locations for those installs?
> (at least per platform, one for win, one for Mac, one for linux). Or
> should I sniff the PATH?
> > Thanks,
> > - Johan
> > 2014-11-26 20:02 GMT+01:00 Danno Ferrin <danno.ferrin at oracle.com>:
> > On Nov 26, 2014, at 11:11 AM, Johan Vos <johan at lodgon.com> wrote:
> > > Hi,
> > >
> > > Earlier today, I uploaded an early access build of the JavaFX 8u40 SDK
> > > Android (Dalvik). See
> > >
> > > for the announcement.
> > >
> > > The source code for this build is in
> > > https://bitbucket.org/javafxports/8u40-rt and that repository started
> as a
> > > mirror of the OpenJFX 8udev at November 15 (so we're not behind too
> > > It is my intention to go over all changes that I had to apply, and to
> > > propose them as patches for OpenJFX. However, I took some shortcuts in
> > > few issues that would pollute the OpenJFX tree, hence I need some time
> > > cleanup first.
> > >
> > > Apart from support for 8u40, the 2 major things in this EA release are:
> > >
> > > 1) we are now using Monocle instead of Lens. That is, we use the
> > > Glass implementation, but still use the Prism eglfb implementation.
> > > story on why this is the case, but eventually we will use monocle
> there as
> > > well.
> > >
> > > 2) we have now support for the android gradle plugin. As a
> consequence, a
> > > JavaFX project with a single build.gradle file can be used to generate
> > > Android Package and install it on a device.
> > > This will make life of developers much easier.
> > >
> > > I think there are 2 more things that are needed in order to lower the
> > > barrier for developers:
> > > 1) IDE integration. With the single build.gradle file, this should be
> > > possible, but I have zero experience in developing plugins.
> > > 2) java(fx)packager integration. It would be so nice if we could just
> > > Android packages using the Java Packager. Would this be an option?
> > >
> > > - Johan
> > This is (now) possible. I don't think it would be distributed with the
> Oracle JDK but I put the hooks in for 8u20 to allow external bundlers to be
> used by the bundling engine. so it can be distributed as a library to be
> used by the plugin.
> > What I need is a list of instructions on what to do, including software
> that is assumed to be installed. If the instructions would start from the
> user providing a set of jars for a JavaFX desktop application, and
> enumerating what metadata beyond that needs to be provided I could automate
> the rest.
> > <javafxandroidstructure.zip>
More information about the openjfx-dev