OpenJFX 8 Backport to Java 7

[Daniel Zwolenski]

There are no legality issues with putting OpenJFX into a Maven repo. The
issues are only with OracleJFX because of the Oracle redistribution
licence. OpenJFX code you can print out and wear on a T-Shirt if you want
;)

Danno, I guess I was thinking more along the lines of a zip containing both
the JAR and the natives being deployed somewhere that the plugin can
download from (and then extract and use as needed). If BinTray (or GitHub
or an FTP server) works better for this I'm totally cool with that, so long
as I can download the zip via code without having to log in or anything.

I think I might need more info from Niklas as to how RoboVM builds with
javafx though. I was assuming he'd just bundle the jfx natives into the
app, but maybe you are right and he does something different. All too new
for me yet so I'll wait for him to put up his blog post about how he got
his sample iOS app working and go from there. I'll work with Niklas to get
the Maven plugin building apps with RoboVM and without JavaFX first, then
I'll try to have a look at including JFX from there.

So at this stage forget I asked and don't worry about it thanks - I'll hit
you with questions when we get there (hopefully in a week or so).



On Wed, May 15, 2013 at 3:29 PM, Tom Eugelink <tbee at tbee.org> wrote:

>
> And then there is the issue of legality. The intention of putting JFX in
> Maven central is very old, I'm not sure if we already have setup an account
> at Sonatype's (it's that long ago). Apparently there is some legal mumbo
> jumbo that someone has to waded through and I'm not running the risk of
> going head to head with Oracle's lawyers. Open source != free.
>
> Tom
>
>
>
> On 2013-05-15 05:37, Danno Ferrin wrote:
>
>> One does not simply
>>
>> <picture of Boromir>
>>
>> Put JavaFX in Maven Central
>>
>> Couldn't resist ;)  It depends on what you mean though.  The jar files are
>> a slam dunk.  The native libs are not so simple, first I have to get them
>> all generated, and I have never attempted to do any java native lib builds
>> on windows.  But if the goal is to make it RoboVM accessible then the java
>> jars are all that is needed since it will be building it's own binaries.
>>
>> Although I have to admit I am partial to BinTray for these files.  After
>> getting the substance jars onto maven central it is much to much of a pain
>> in the neck to automate if you are not building with maven already.
>>  Making
>> developers put in a custom repo address seems much easier than the hoop
>> jumping and dancing it takes to get it into central the first time.
>>
>> On Tue, May 14, 2013 at 9:29 PM, Daniel Zwolenski <zonski at gmail.com>
>> wrote:
>>
>>  Nice. I've got a rough cut of a maven plugin working for RoboVM. Just
>>> waiting on sonatype to grant access to the repo for this and then the
>>> first
>>> version should be live (ie probably over the next week or so).
>>>
>>> If this jfx backport (when it's working) could be deployed into Maven
>>> Central (especially the iOS build of it) then the plugin could
>>> automatically include it into the path for RoboVM. One less step for
>>> users
>>> to have to do manually. Have you got plans or are you willing to get it
>>> into Central (which I assume a RoboVM gradle plugin would benefit from as
>>> well)?
>>>
>>> I've got only a little bit of time to spare at the moment so keen to
>>> focus
>>> that on the RoboVM side of it, but if no one else is up for getting the
>>> backport into Central I'll put it on (the bottom of) my todo list.
>>>
>>>
>>> On 15/05/2013, at 1:05 PM, Danno Ferrin <danno.ferrin at shemnon.com>
>>> wrote:
>>>
>>>  I've started a backport codebase for OpenJFX8 to Java 7.
>>>>
>>>> https://bitbucket.org/narya/**jfx78 <https://bitbucket.org/narya/jfx78>
>>>>
>>>> The intent is to provide OpenJFX 8 code to Java 7 based VMs, whether it
>>>>
>>> is
>>>
>>>> Oracle's JVM or other Java7 based VMs (such as RoboVM or Dalvik).  It's
>>>>
>>> not
>>>
>>>> soup yet, it still needs some more open source libraries.  Right now the
>>>> compile breaks at the graphics module because the
>>>>
>>> com.sun.javafx.accessible
>>>
>>>> packages have not been open sourced yet.
>>>>
>>>> For the record I am only concerning myself with the gradle build and not
>>>> the current Ant based build.
>>>>
>>>> Generally speaking the plans are to deal with the incompatibilities as
>>>> mechanically and predictably as possible.
>>>>
>>>> * For lambdas expanding them to inner classes.  IntelliJ has a code
>>>> intention for this I am using
>>>> * For defender methods push down the default implementation to first
>>>> line
>>>> implementors, giving it the same effect with more lines of code.
>>>> * For the new JSR-310 Date classes bring in the ThreeTen jars (
>>>> https://github.com/ThreeTen/**threetenbp<https://github.com/ThreeTen/threetenbp>)
>>>> (but it's not there yet)
>>>> * For java.util.function.Predicate<**T> replace it with Callback<T,
>>>>
>>> Boolean>
>>>
>>>> If anyone is interested in contributing and wants commit access, just
>>>>
>>> ask.
>>>
>>>> --Danno
>>>>
>>>
>
>