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

[Danno Ferrin]

On Wed, Oct 10, 2012 at 9:28 AM, Mark Fortner <phidias51 at gmail.com> wrote:

> Hi Peter,
>
> Comments below.
>
>
> > 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.



> 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
be different for sure.

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

--
There is nothing that will hold me back.  I know who I am....
I remember wher I came from, and I feel stronger for knowing.
Zane, Ninja of Ice.  Ninjago S01E07