Compiling 8u20-b26 for iOS

[Johan Vos]

Hi Niklas,

Yes, the 8u20-rt repository in javafxports is the final 8u20 code of
OpenJFX. It contains some minor changes since 8u20 was frozen but there
were still some changes to be made.
Apart from the 8u20-rt repository, we also have a 8u-dev-build repository
that will copy the tools and a compat.jar into the dalvik-sdk created by
8u20-repo. The compat.jar contains the required classes that are missing in
the Dalvik runtime. Caveat: between different Android API levels, classes
are added and changed on the fly, so something that works on API lvl 19
might not work on API lvl 18.

As for the WebKit support: internally, we use the Android WebView for
rendering the WebPage. The Android WebView relies on the webkit engine as
well.

<rant>
If you're used to the powerful JavaFX WebView and WebEngine, you should
have a look at the limited Android WebView API. Want to get a DOM
representation of the current webpage? Google it and judge which solution
is the least dirty one. The JavaFX WebView simply dwarfs the Android
WebView. Good enough, Android developers can now use JavaFX as well.
</rant>

- Johan



2014-09-03 8:25 GMT+02:00 Niklas Therning <niklas at therning.org>:

> @Johan: Maybe I should work against the javafxports code instead and send
> you a PR? We can coordinate our efforts there on Android and iOS and then
> try to get things merged upstream later on? I'm guessing that it will be a
> lot easier for me to get your code running with RoboVM as you must have
> already made sure it works with the Android runtime classes, right?
>
> I'm cloning the 8u20-rt repository as we speak. Is that the repo I want to
> use? Is it based on 8u20-b26?
>
>
> On Tue, Sep 2, 2014 at 7:56 PM, Johan Vos <johan at lodgon.com> wrote:
>
>> I have to create a JIRA issue with patch as well for the Android port.
>> However, I'm not 100% convinced I'm doing it right, so I keep it open for a
>> while.
>> The difficulty I face is that the compile tasks are not "standard" gradle
>> java compile tasks (we include the java plugin in the dalvik.gradle file)
>> and they are mixed with ant javac compilations.
>> The mix of my limited knowledge of both ant and gradle make me feel not
>> entirely comfortable with the solution, but at least it was good enough to
>> give 8u20 b2 a try.
>>
>> - Johan
>>
>>
>> 2014-09-02 16:44 GMT+02:00 Kevin Rushforth <kevin.rushforth at oracle.com>:
>>
>>>  > I should probably create an issue for all of this and attach a
>>> patch, right?
>>>
>>> Yes, please. We can get the patch into 8u-dev.
>>>
>>> -- Kevin
>>>
>>>
>>> Niklas Therning wrote:
>>>
>>>> I couldn't keep my hands off and by looking at how it's done in
>>>> dalvik.gradle from javafxports [1] I managed to get it to build the iOS
>>>> web.jar. Here's the patch for ios.gradle:
>>>>
>>>> diff -r e56a8bbcba20 buildSrc/ios.gradle
>>>> --- a/buildSrc/ios.gradle Thu Jul 24 21:23:07 2014 -0700
>>>> +++ b/buildSrc/ios.gradle Tue Sep 02 16:35:41 2014 +0200
>>>> @@ -340,7 +340,17 @@
>>>>      apply plugin: 'java'
>>>>
>>>>      compileJava {
>>>> -        enabled = false
>>>> +        sourceSets.main.java.srcDirs = ['src/ios/java'];
>>>> +    }
>>>> +    sourceSets {
>>>> +        main {
>>>> +            java {
>>>> +                srcDirs= ['src/ios/java']
>>>> +            }
>>>> +        }
>>>> +    }
>>>> +    dependencies {
>>>> +         compile files("../graphics/build/classes/ios");
>>>>      }
>>>>
>>>>      afterEvaluate {
>>>>
>>>>
>>>> Let me know if you want me to create a JIRA and post this there
>>>> instead. This patch helped me get past the first problem with the builders
>>>> project failing. I then had to fix a few compilation problems in the web
>>>> module's iOS code. A few classes (PopupFeature and PromptData) were missing
>>>> and a few of the others had to be brought up to date with the code in
>>>> src/main/. Haven't been able to test the patched web iOS code yet but at
>>>> least it compiles now. I should probably create an issue for all of this
>>>> and attach a patch, right?
>>>>
>>>> [1] https://bitbucket.org/javafxports/8u20-rt/src/
>>>> 772ccf341457a1bbabef278cfe4dd6b22f5d7e72/buildSrc/dalvik.
>>>> gradle?at=default
>>>>
>>>>
>>>> On Tue, Sep 2, 2014 at 4:34 PM, Kevin Rushforth <
>>>> kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>> wrote:
>>>>
>>>>     I'll take a look at the build order, but it sounds like a bug.
>>>>     Perhaps you can just locally disable the builders or add a
>>>>     dependency on the compilation task for the IOS web files.
>>>>
>>>>     As to your other question, Richard is right that we omit lib/ext
>>>>     from compilation, but there can be issues in doing this (e.g.,
>>>>     when running tests or building apps). We recommend that you remove
>>>>     (not just rename) the jfxrt.jar from the JDK you use to build.
>>>>
>>>>     -- Kevin
>>>>
>>>>
>>>>
>>>>     Richard Bair wrote:
>>>>
>>>>>     I'll let one of the other guys answer about the web component
>>>>> build order, but ...
>>>>>
>>>>>     On Sep 1, 2014, at 11:58 PM, Niklas Therning <niklas at therning.org>
>>>>> <mailto:niklas at therning.org> wrote:
>>>>>
>>>>>
>>>>>
>>>>>>     Also, how is the jfxrt.jar that comes with my Java8 installation
>>>>>> treated by
>>>>>>     the build? I guess it is ignored since otherwise I wouldn't get
>>>>>> any
>>>>>>     compilation problems due to missing WebView etc since those
>>>>>> classes are in
>>>>>>     Java8's jfxrt.jar?
>>>>>>
>>>>>>
>>>>>     The jfxrt.jar that comes with the JDK is in the lib/ext directory
>>>>> (as is Nashorn). We simply omit both from the class path when we build by
>>>>> setting java.ext.dirs= (to empty).
>>>>>
>>>>>     Richard
>>>>>
>>>>
>>>>
>>>>
>>
>