No JavaFX for iOS, Android or WP (original) (raw)

Mark Fortner phidias51 at gmail.com
Wed Oct 10 11:51:28 PDT 2012

Cheers,

Mark Hi Danno,

> I am preferring to use Gradle these days. Nevertheless the issue of > putting JavaFX in a Maven Repository > is an important. Because JavaFX is not pure Java, the problem with > linking with native library is a major concern. > > Whatever JavaFX JAR you put in a artifact repository, whether SonaType > or Artifactory there has to be way to guarantee the code in the JAR > can always find the native libraries. Oracle have not come with a > scheme. I do not know of a safe way to do this portably that is cross > platform and work across all systems with causing a break if one or > the other dependencies are upgraded. The version, the native library > and the potential upgrades are the sticking problem. > > Then there is a licensing of the JavaFX Runtime and distribution of > Oracle's implementation. > Agreed. The assumption seems to be that if you use the Ant tasks to build, then you're OK. Everything else, you're on your own. Most of the organizations I've worked for left Ant behind 10 years ago. A mojo version of the Ant tasks would make deployment easier. This is my problem with Maven the build system. You have to write and deploy classfiles to do anything but derivitives of current build styles. While it is good that it forces truly horrible build styles to conform to a convention as the path of least resistance, when you have to leave the trodden path it is incredibly painful. That is why I advocate Gradle for a new build, you can script your special cases in place and still deploy to a Maven repository. Maven the dependency system is generally speaking a good thing.

The only time I've had to deviate from the well-trodden path is when I've had to take an Ant project, and add Maven to it without breaking the Ant build. I've looked at Gradle, and used it on a Groovy project that I've worked on, but I've found that the majority of the people still use Maven. In a typical technology adoption curve, Gradle seems to be on the leading edge of the curve, Maven on the peak of the curve, and Ant on the trailing edge. My thought was to try and get the JavaFX team to focus on the needs of the 80% of the enterprise developers who are out there and are looking at converting their existing Swing application into a JavaFX app.

A maven archetype for

creating JavaFX projects would go a long way to making things easier. You simply run the archetype all of your dependencies, Eclipse/NetBeans project files, runtime environment variables are created for you. You could even add a starter application.

For the most part it is the existing java archetype is already there. But what would excite me more would be conventions for how to add some of the standard additions to the file layout, so instead of putting stuff in the classpath and wiring in some ant calls you just drop some files in, configure nothing, run the appropriate goal or task, and get your bits. For example, all of this under src/main/deploy deploy.xml - xml config describing some of the values, such as jvm args, app name, etc with defaults driven by the POM icon.png - your default icon icons/iconxx.png - multi sized icons package//... - per packaging depoyments. Platoform would be macosx, win, webstart, etc. Could also have a deploy.xml to override for local settings. We would need names and locations for signing keys, gatekeeper on mac would

Agreed. It needs to just as easy as you describe. Unfortunately, it's not there yet. I think Richard mentioned in his quarterly report that he was working on making it easier, but I haven't seen any specifics about this.

ps. why doesn't the list set the mailing list as the reply to?

Grrr. ;-)

More information about the openjfx-dev mailing list