Including the list. Thanks Tom, good to double check the licensing issues.
As I understand it all of the OpenJDK and OpenJFX is released under GPLv2 http://openjdk.java.net/legal/gplv2+ce.html I interpret this to mean that it can be redistributed, modified and generally used however we want so long as we distribute it with the same licence. I interpret that to mean we can both deploy any and all openjfx classes and libraries into OSS Maven and also modify the code (as done with the 78-backport) and distribute that via Maven too. If anyone from Oracle has a problem with that, let me know asap. In the absence of any objections I am pushing ahead with the deployment to Maven. On the same topic, my plan is to push only the iOS builds of the 78-backport at this stage. I intend to deploy the iOS jfxrt.jar using the following details: groupId: net.java.openjfx artifactId: openjfx-78-backport version: 1.8.0-ea-b96.1 classifier: ios Where the version is the OpenJFX version the backport was last merged with, plus an extra number for whatever release the backport is up to relative to that build (e.g. we might do several releases of the backport per build of OpenJFX). I also intend to zip up all the native files for the backport and deploy this zip as: groupId: net.java.openjfx artifactId: openjfx-78-backport-native version: 1.8.0-ea-b96.1 classifier: ios Note that both of the above assume that the jfxrt.jar is not architecture specific (the same jar is used on i386 and armv7) and the zip file will contain the native libs for both architectures. If anyone has any objections to any of that or better suggestions, shout out quickly. With some luck this will start to happen in the next day or two and once it's up it's up. You cannot remove or change a file once it is in Maven Central except in extreme cases like licence violation, in which case it is a pretty involved and messy procedure. For builds of OpenJFX other than the backport (including the jfx packaging tools) I have a very strong preference for the JavaFX team to provide me (or anyone willing to get involved with this) all the various built binaries for all the various OS's and architectures and then I will push these into Maven. I prefer this as I really don't like the idea of us out in the community building these in bits and pieces (you do Linux, I'll do windows, etc) with all the ways that can go wrong (accidental mistakes, viruses, malicious people doing bad stuff just for kicks, etc). It would obviously be ideal if Oracle just added a simple push to Maven at the end of their automated build system but they are not that way inclined. Getting the binaries from them would be at least half way there and reduce the scope for problems. >From what I've been told, I wouldn't expect these binaries to be provided in a way that makes them easy to get at and upload anytime soon due to internal red tape, so if you are holding out for this stuff to end up in Maven, best to raise that issue with the JFX guys. On Thu, Jul 25, 2013 at 5:09 PM, Tom Schindl <tom.schi...@bestsolution.at>wrote: > Hi, > > Before you push your stuff to maven-central make sure you are not > running into license problems. I [line removed] was pointed then to the > license agreement that apply > to JSRs (not sure this also applies to javafx because it is NOT JSRed). > > In the agreement it reads: > > > 2. Distribute implementations of the Specification to third parties for > their testing and > > evaluation use, provided that any such implementation: > > (i) does not modify, subset, superset or otherwise extend the Licensor > Name Space, or > > include any public or protected packages, classes, Java interfaces, > fields or methods within > > the Licensor Name Space other than those required/authorized by the > Specification or > > Specifications being implemented; > > (ii) is clearly and prominently marked with the word "UNTESTED" or > "EARLY ACCESS" > > or "INCOMPATIBLE" or "UNSTABLE" or "BETA" in any list of available > builds and in > > proximity to every link initiating its download, where the list or link > is under Licensee's > > control; and > > (iii) includes the following notice: "This is an implementation of an > early-draft specification > > developed under the Java Community Process (JCP) and is made available > for testing and > > evaluation purposes only. The code is not compatible with any > specification of the JCP." > > The grant set forth above concerning your distribution of > implementations of the > > specification is contingent upon your agreement to terminate development > and distribution > > of your "early draft" implementation as soon as feasible following final > completion of the > > specification. If you fail to do so, the foregoing grant shall be > considered null and void. > > Like I said this is from a JSRed spec but I wanted to make sure you > double check the license of JavaFX because once you pushed to maven > central it might be hard to remove it once JavaFX8 is released (iii)! > > Thanks for pushing RoboVM, e(fx)clipse will add support for your > maven-plugin and RoboVM deployment options (most likely also ontop of > the above mentionned maven-distro) with the next release in autumn. > > Tom > > On 25.07.13 08:46, Daniel Zwolenski wrote: > > Ok, thanks. > > > > Is it architecture specific, i.e. within a target OS does each platform > > require it's own jfxrt.jar or do they all share the same? Most > > specifically, on iOS do the armv7 and i386 architectures use the same JAR > > and just different lib files or is there a specific jfxrt.jar for each? > > > > In general it would be great to see a list of all the distinct JARs that > > can be produced e.g. something like: > > > > jfxrt-ios.jar > > jfxrt-win.jar (or is jfx-win32.jar and jfx-win64.jar, etc) > > jfxrt-osx.jar > > jfxrt-linux.jar > > jfxrt-pi.jar > > > > I imagine that list is very wrong (pi, linux, especially) - what's the > real > > list? This ( > https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX) > > kind of hints at it but for example if I want to build for win32 do I > have > > to be on a win32 system or does building on a 64 bit platform produce the > > files needed for both, etc? > > > > Even better if we had some document that outlined all the supported > > platforms the JAR and the native libs built for that platform in a nice > big > > table. Bonus points for clear cut steps and commands to build each one, > > which platforms you can run on and what gradle command to run. > > > > > > > > > > On Thu, Jul 25, 2013 at 3:32 PM, Kevin Rushforth < > kevin.rushfo...@oracle.com > >> wrote: > > > >> Yes, jfxrt.jar is platform-specific. On the desktop there are > >> platform-specific glass and Prism classes (not sure about the WebKit > >> classes). On embedded platforms (Linux-arm, IOS, Android) there are many > >> differences. > >> > >> -- Kevin > >> > >> > >> > >> Daniel Zwolenski wrote: > >> > >>> Obviously there are native libs (dlls, etc) that JFX uses that are > outside > >>> of the jfxrt.jar. > >>> > >>> But is the actual jfxrt.jar produced by the build generic and able to > be > >>> used on any platform (so long as the natives are also present) or is it > >>> platform specific itself? > >>> > >>> We are getting close to the ios/backport stuff working (as well as it > can > >>> at this stage) and are aiming to start putting stuff in Maven soon. > Just > >>> want to make sure I get the separations as clean as possible because > once > >>> it's in Central it doesn't ever leave. > >>> > >>> Cheers. > >>> > >>> > >> > >
