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

[Daniel Zwolenski]

On 15/10/2012, at 11:49 PM, Tom Schindl <tom.schindl at bestsolution.at> wrote:

> [Please note I have no idea of all how maven works and how it does the
> classloading, ... .]
> 
> Well if this stuff is found at a well defined place why does the plugin
> have to redistribute them?
> 
> e.g. in e(fx)clipse I simply generate a ant-build script which uses the
> JDK-Location to find the fx-ant additions and the javafxrt.jar when
> compiling.

Yes this an option. If someone wants to build this plugin they will likely want to go down that road if they can't legally bundle the tools in their own code. 

This isn't an option for the actual rt.jar though as you can't hijack the compile path in the same way as you can the assembly tool path. Ie this will only be a practical option after the rt is on the bootclasspath as originally discussed. 

Which is why this plugin hasn't been written by the community yet - waiting on oracle. 


> 
> Would the easiest thing for a maven build be that it generates an
> ant-file and then launches ant?

No, Maven can call ant tasks so there is no need to generate an ant file. Maven users would not be overly happy with doing this though. 

Maven uses convention, ant uses configuration. Maven users will not be happy configuring a whole lot of ant tasks. The plugin would work out all the ant settings from the structure of the project. A maven user would expect to setup a build for their maven project by simply specifying the plugin reference and one or two lines of config (eg jnlp vs applet). The rest would all just happen magically.

It's all pretty moot at this stage till the bootclasspath issue is fixed anyway. I was just pointing out that there would be more work and more challenges after this, whereas I think there might be a conception that this will be resolved (several maven requests were already marked incorrectly as resolved even before the bootclasspath fix has been done). 

Maven users won't be super impressed about having to manually install something like wix to do native builds too. Maven users are spoilt and used to most things just magically happening. This one would probably rate as just an annoyance though whereas the lack of plugin above would be a real deterrent for most. 

> 
> Tom
> 
> Am 15.10.12 14:39, schrieb Daniel Zwolenski:
>> Just for clarity, the bootclasspath addition will only solve the first part of the Maven issue, ie the jars will be available to *compile* against. 
>> 
>> For actual *packaging* for deployment, JFX has special ant tools, which creates bundles (for webstart, applet and native) and these bundles are quite magic so not trivial to assemble without the ant tools. As such these Ant tools would need to be ported (or wrapped by) a Maven plugin in order to have a clean JFX Maven build that is inline with what you would be accustomed to when building say a webapp with Maven. 
>> 
>> You could of course callout to the ant tasks but the build is far enough off a normal Maven build doing this that you'd likely be better off just using Ant (+ivy) as it would be simpler/cleaner. Or there's Gradle.
>> 
>> If the bootclasspath thing happens it does at least partially resolve the long standing legal hurdles to Maven integration so the community *may* well be able to (finally) build this plugin. However I imagine the legal issue will still stand with regards to the Jars used by the packaging tools (as these likely won't be on the bootclasspath), which means the plugin probably legally won't be able to redistribute these tool jars making it harder to implement such a plugin. 
>> 
>> Any such Maven plugin and support will be the full responsibility of the community unless there was a change in current stance. The Oracle JFX team support ANT only, all other build platforms are left as an exercise for the reader. 
>> 
>> 
>> 
>> On 15/10/2012, at 11:06 PM, Claus Luethje <Claus.Luethje at osys.ch> wrote:
>> 
>>> Oh, I must have missed this info. In this case, let's hope JavaFX in soon pushed into the bootclasspath.
>>> Claus
>>> 
>>> -----Original Message-----
>>> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Tom Schindl
>>> Sent: Montag, 15. Oktober 2012 13:54
>>> To: openjfx-dev at openjdk.java.net
>>> Subject: Re: No JavaFX for iOS, Android or WP - why not?
>>> 
>>> Well once javafx is on the bootclasspath this doesn't make any sense so time is better invested in pushing into the bootclasspath in 7u something which is the last info I got from Kevin (See
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7166330)
>>> 
>>> Tom
>>> 
>>> Am 15.10.12 13:45, schrieb Claus Luethje:
>>>> +1 for the maven support
>>>> 
>>>> -----Original Message-----
>>>> From: openjfx-dev-bounces at openjdk.java.net 
>>>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark 
>>>> Fortner
>>>> Sent: Mittwoch, 10. Oktober 2012 17:28
>>>> To: openjfx-dev at openjdk.java.net
>>>> Subject: Fwd: Re: No JavaFX for iOS, Android or WP - why not?
>>>> 
>>>> 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.   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.
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>>>  - *Webstart deployment *- this is still problematic.  Currently 
>>>>>> when
>>>>> you
>>>>>>  push new artifacts to your web server, it's not replacing the
>>>>> existing JARs
>>>>>>  in the user's cache -- despite what the documentation says.  The
>>>>> "special"
>>>>>>  javafx tags aren't documented well enough and presume that you're
>>>>> using the
>>>>>>  Ant tools to generate the JNLP.  And getting shaded jars is next to
>>>>>>  impossible.
>>>>> 
>>>>> I do not have an answer to this web start problem. I do assume you 
>>>>> can upgrade Java 7.
>>>>> 
>>>>> 
>>>> 
>>>> I'm currently running Java 7.
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>>>  - *Charts* - support for zooming and panning within the charts.
>>>>> Support
>>>>>>  for drawing on top of charts.
>>>>> 
>>>>> The controls and charts code is open source, go and implement your 
>>>>> chart component.
>>>>> Start with a copy of the line chart and hack it.
>>>>> 
>>>>> 
>>>> Not really looking to hack JavaFX classes to support basic functionality.
>>>> I figure if I can do zooming and panning in Google Charts in a web browser, then I should be able to do the same with JavaFX.  BTW, I tried hacking LineChart, and then quickly realized I would also have to hack NumberAxis because some fool made it final.  The scope of my hacking quickly started to grow so I stopped before it got out of hand.
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>>>  - *Support for Swing components within JavaFX. * If the goal is to
>>>>>>  replace Swing, then this is one of those essential capabilities 
>>>>>> that
>>>>> needs
>>>>>>  to be in place. The current examples only demonstrate how to put
>>>>> JavaFX
>>>>>>  components within Swing applications.  Unfortunately, if you want 
>>>>>> to
>>>>> reuse
>>>>>>  any existing components (like JFreeCharts for example) within 
>>>>>> your
>>>>> project,
>>>>>>  you're SOL at the moment.
>>>>> 
>>>>> They is not going to be 100% free ride on this extra third party 
>>>>> functionality.
>>>>> 
>>>>> 1) Modify JFreeChart and port some of it or all of it to JavaFX
>>>>> 2) Hack the existing Chart package until it gets you 80/20 of what 
>>>>> you want
>>>>> 
>>>> 
>>>> Unfortunately, if they're positioning this as a replacement for Swing, then they're going to need to have some way of support Swing components.  There are just too many Swing libraries out there that may never get ported over.
>>>> If SWT can be supported, I don't see why Swing can't.  Either the original owners don't want to port them, don't have the funds to do it (this is especially true with academic libraries used for scientific applications), or have abandoned the code base.
>>> 
>>>> 
>>>> When you're contracting, porting a library is typically not part of the scope, since it's assumed that whatever components you're using already support 80% of what you want, and you just need to add functionality specific to the problem domain you're working in.
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>>>  - *Support for an EventBus.*  Currently, there's a lot of point2point
>>>>>>  event code that you have to write to fire and listen to events.  
>>>>>> It
>>>>> would
>>>>>>  make for a much more useable codebase if you could simply publish and
>>>>>>  subscribe to events at the application level.
>>>>> 
>>>>> Why not write a JavaFX extension framework that maps JavaFX Event to 
>>>>> a MessageBus implementation.
>>>>> 
>>>> 
>>>> I'm not saying I can't write this, I'm saying I shouldn't have to.  The point2point event model breaks down after a while especially in a highly interactive application, and results in memory leaks when you can't or don't disengage your listeners.
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>>>  - *Release the source.*  It's a royal pain to have to download the
>>>>>>  source through mercurial rather than simply read it as you do with the
>>>>>>  Swing code or download it as you do with any Maven package.
>>>>>> 
>>>>> 
>>>>> The source code is there as JavaFX 2.2 as openjfx already.
>>>>> I think you meant make the source code also a downloadable distribution.
>>>>> 
>>>> 
>>>> Actually, since it currently ships with Java 7, the source code should be included just as the source code for Swing is included.
>>>> 
>>>> 
>>>>> 
>>>>> Hack the build.xml in the openjfx project, and contribute the Ant target.
>>>>> 
>>>>> I also note that there should be a standalone JavaFX Doc as 
>>>>> distribution
>>>>> 
>>>> 
>>>> Usually these are part of the standard Maven build -- so if they built with Maven they would get that for free.
>>>> 
>>>> 
>>>>> 
>>>>> Ditto - hack the build.xml to javadoc and zip up the javadoc
>>>>> 
>>>>> Contrib the patch back to the team
>>>>> 
>>>>>> There's also some work that needs to be done to make it easier for 
>>>>>> people to participate.  I have 3 accounts at the moment: one for 
>>>>>> this mailing list, one for the forums, and one for JIRA.  Can we 
>>>>>> just boil that down
>>>>> to
>>>>>> one, and let me login with Facebook or Google credentials?
>>>>>> 
>>>>> 
>>>>> Have you heard of the online services Google Onepass or LastPass or 
>>>>> Yahoo Super wallet?
>>>> 
>>>> 
>>>> Not really looking for an alternative, merely the ability to sign on without having to create new accounts everywhere.  One of the goals of the JavaFX project (described in Richard's quarterly report) is to increase
>>>> community participation.   Most of what I've mentioned are items that
>>>> should lower those barriers to entry.
>>>> 
>>>> 
>>>> Mark
>>>> 
>>> 
>>> 
>>> -- 
>>> B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
>>> ------------------------------------------------------------------------
>>> tom schindl                 geschäftsführer/CEO
>>> ------------------------------------------------------------------------
>>> eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833
>>> http://www.BestSolution.at                      phone    ++43 512 935834
> 
> 
> -- 
> B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
> ------------------------------------------------------------------------
> tom schindl                 geschäftsführer/CEO
> ------------------------------------------------------------------------
> eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833
> http://www.BestSolution.at                      phone    ++43 512 935834