Deployment: native application bundles

[Igor Nekrestyanov]

hi, thanks for all questions.

Please keep them coming (bugs and suggestions are very welcome too!),

> The Ensemble MSI install worked for me on Windows 7 no problems. I 
> haven't tried building my own app as yet though.
>
> It installed into 'C:\Users\zonski\AppData\Local\Ensemble2'. 
> Installing into Program Files is probably more correct on windows. Is 
> this 'appdata' the intended final location, or is this just for 
> getting it all running for now?
Original goal was to be able to install without requiring admin permissions.
Both MSI and EXE installers are currently build to do this.

It is possible to customize install location and make it system wide by 
tweaking WiX/Inno Setup template files.
Clearly we want to expose better APIs for customization but it is not 
clear what are importnat config parameters and how to expose them
in more or less cross platform way, hence we decided that for 2u2 we 
will provide an easy way to build basic package and do minimal customization
as well as (very) advanced way for advanced users.

Based on feedback we will figure out how to expand built-in 
configuration APIs for future releases.

I am planning to post more about package customization options and other 
tricks&tips but i am amateur blogger and slow typer, so it will take me 
few days :)

Perhaps we should reconsider and produce EXE to be user level 
installation and MSI to be system level by default.
I believe it is also possible to pass parameters to msiexec to overwrite 
some of MSI settings (end this is not unusual in the enterprise 
deployments).
However, i had not tried if it is possible to install this MSI system 
wide (and i am not sure if my MSI expertise is deep enough to craft MSI 
that can do both,
suggestions are very welcome).
>
> Is the source code available for this at all?
Sorry, it is part of deploy/packager module that is not open sourced yet.
> If not, I'm very interested in how the 'exe' launcher code looks. Is 
> this code you've written or part of one of the tools you've made use 
> of? I'm particularly interested to see how it starts the app - does it 
> just kick off another process on the executable jar via something like 
> 'java -jar ensemble.jar' or does it try to run the Java app within 
> it's own 'exe' process somehow (I'm assuming the later?).
yes, launcher will instantiate JVM in the launcher process.
Check out list of processes when sample app is running. There is no 
java.exe but there is Ensemble.exe
>
> I notice also that the jfx DLLs have been copied straight into the 
> 'jre/bin' directory.
Starting 7u6 JRE/JDK will include JavaFX as part of Java installation.
So, nothing special here. It is just runtime image.
> Is this how you see all native dependencies playing out, i.e. if my 
> application uses other native libraries how do I package them into the 
> build and where will they be installed to in the extracted directory?
No, i do not think application resources will go into runtime.
Application resources will stay in the "app" folder (native libs too).

The approach here is to "bundle" app without requiring to rewrite it.
During the development cycle your build output should have copy of 
application you can execute and debug (but it depends on environment, 
i.e. java+javafx runtime).
Bundle is essentially
      copy of this application + java runtime  + launcher

Having said that i had not tried to craft example with native libraries 
myself. Will certainly try to do.
> One more question: when we say we have to build on the native platform 
> to get the correct deployments, does that include 32bit vs 64bit? I'm 
> guessing I could have a 32bit and 64bit JDK installation on the one 
> machine and build a version of my app for each, but correct me if I'm 
> wrong on this.
yes, two installations should do.

Currently ant task will try to use RUNNING version of java as source for 
cobundle.
If it is not appropriate (e.g. java 6 that is not javafx cobundle) then 
it bundled app will not be created.

In the future we may add option to specify which JDK to use as import 
for bundle creation but for now we are taking shortcuts to avoid 
exposing too much (kind of late in release).
> I assume there's no way for a single JDK installation to produce both 
> 32 and 64bit versions? 
No, as currently JDK installations do not include both 32 and 64 bit 
bits. After all we are copying them into bundle.

-igor
> Very, very nice start to this all!
>
> Cheers,
> Dan
>
>
> On Fri, Jun 15, 2012 at 5:16 PM, Igor Nekrestyanov 
> <igor.nekrestyanov at oracle.com <mailto:igor.nekrestyanov at oracle.com>> 
> wrote:
>
>     Hi,
>
>     One thing we are adding to JavaFX packaging tools in 2.2 is
>     ability to produce native application bundles:
>     https://blogs.oracle.com/talkingjavadeployment/entry/native_packaging_for_javafx
>
>     We are not seeing this as the only way to deploy JavaFX
>     applications -- webstart, embedded applications
>     and doubleclickable jars are first class citizens (and it would be
>     great to explore other options).
>     But we hope it might be good option for many deployment scenarios.
>
>     Please give it a try and provide feedback (and report bugs of course),
>
>     -igor
>
>