No JavaFX for iOS, Android or WP - why not?

[Mark Fortner]

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/icon_xx.png - multi sized icons
> package/<platform>/... - 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.


> <sidebar>
> ps. why doesn't the list set the mailing list as the reply to?
>
>
Grrr.   ;-)