OpenJFX 8 Backport to Java 7
Tom Eugelink
tbee at tbee.org
Tue May 14 23:58:22 PDT 2013
Good to hear the license of OpenJFX allows that.
There is no problem with putting the native libs into Maven as well and differentiating them with the classifier tag. This keeps all the files neatly in one place, supports nested resolution via Maven's dependencies, proxy repo's on Nexus on Artifactory easily copies them to local repo's, etc, etc.
On 2013-05-15 08:06, Daniel Zwolenski wrote:
> 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 <mailto: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 <mailto: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 <mailto:danno.ferrin at shemnon.com>> wrote:
>
> I've started a backport codebase for OpenJFX8 to Java 7.
>
> 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) (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
>
>
>
>
More information about the openjfx-dev
mailing list