Confused about status of JFX+JRE cobundling

[Igor Nekrestyanov]

On 6/19/12 12:49 AM, Tom Schindl wrote:
> Am 19.06.12 09:37, schrieb Igor Nekrestyanov:
>> On 6/19/12 12:15 AM, Tom Schindl wrote:
>>> * the unbalanced decision to not provide SDK-Drops as zips makes
>>>     repackaging for different platforms complex
>> What other platforms you are referring to? Other Linux distros?
> No I'm talking about windows and mac. Say I'm a win32 user and want to
> package an application for users on mac and win32. How would you advise
> to do so?
ok, this is valid use case and these is a feature request for cross 
platform packaging.
We are looking for ideas how to implement it (and contributions too), 
please comment in JIRA if you know
how to approach it.

It does not directly related to JRE/JDK cobundling though.
If JDK will be available as .zip download it will solve it for you?
(not sure if this will be happening)

>>> there is now a missmatch between those not wanting to install a JDK
>> update and use the JavaFX-SDK because native packaging with fx:deploy
>> task is not working for them.
>>
>> What is the problem with having multiple versions of JDK on the system?
>> Unlike runtime these are fully independent ...
>>
> JavaFX previews are shipped on a very regular base so now with the
> co-bundleing I'm downloading the whole JDK all the time although I'm
> only interested in the latest JavaFX.
i see.

It does not seem to be too severe to me though.
Loading extra 50Mb a week to get latest SDK is not much these days.
And i see beta builds are still available as standalone archives here:
     
http://www.oracle.com/technetwork/java/javafx/downloads/devpreview-1429449.html

Some changes on Java side are prompted by JavaFX requests. Tight 
coupling helps with this.
Also, no need to install duplicate deployment stack makes web deployment 
more robust.

-igor
>
>>> Is it really such a big problem to find out java.home for the ant-task
>> and packaging this up? Just asking
>>
>> Current native packaging support makes a lot of simplifying assumptions
>> on bundle configuration as we do not want to expose too many APIs in a rush
>> (and we likely will provide more flexible APIs in a future for use cases
>> that will be popular).
>> Decision to use current JDK cobundle as a source for native bundle is
>> one of these simplifications. It was not motivation for cobundling Java
>> and JavaFX in JDK,
>> it is another way - because JDK is true cobundle we had option to
>> simplify things.
>>
>> -igor
> Tom
>