Re: CFV: New OpenJFX Committer: Johan Vos

[Danno Ferrin]

Vote: Yes

On Wed, Dec 23, 2015 at 5:19 PM, Richard Bair 
wrote:

> Vote:  YES
>
> > On Dec 22, 2015, at 6:10 PM, Jasper Potts 
> wrote:
> >
> > Vote: yes
> >
> > Sent from my iPhone
> >
> >> On Dec 22, 2015, at 5:03 PM, Alexander Kouznetsov <
> alexander.kouznet...@oracle.com> wrote:
> >>
> >> Vote: yes
> >>
> >> Best regards,
> >> Alexander Kouznetsov
> >> (408) 276-0387
> >>
> >>> On 21 дек 2015 11:45, David Hill wrote:
> >>>
> >>> I hereby nominate Johan Vos to OpenJFX Committer.
> >>>
> >>> Johan Vos (jvos) has been active in the OpenJFX community, and
> instrumental in the maturity of Monocle, the owner of the Android and IOS
> ports and is an OpenJFX Author.
> >>>
> >>> A list of Johan's commits is also available by the following links
> >>>
> >>> http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=jvos
> >>> http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=johanvos
> >>>
> >>> Votes are due by January 5th, 2016.
> >>>
> >>> Only current OpenJFX Committers [1] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this mailing list.
> >>>
> >>> For Lazy Consensus voting instructions, see [2]. Nomination to a
> project Committer is described in [3].
> >>>
> >>> [1] http://openjdk.java.net/census#openjfx
> >>>
> >>> [2] http://openjdk.java.net/bylaws#lazy-consensus
> >>>
> >>> [3] http://openjdk.java.net/projects#project-committer
> >>>
> >>> Thanks,
> >>>
> >>> Dave
> >>
>
>

Re: Bulk packager integration

[Danno Ferrin]

> On Nov 25, 2015, at 6:49 PM, Kevin Rushforth  
> wrote:
> 
> 1) I get the following error if I apply the patch and do a build:
> 
> :fxpackager:compileJava/localhome/kcr/javafx/9-jake-kcr/jfx/rt/modules/fxpackager/src/main/java/com/oracle/tools/packager/JLinkBundlerHelper.java:3:
>  error: package com.sun.tools.jdeps does not exist
> import com.sun.tools.jdeps.Main;
>   ^
> 
> Does this require a newer version of JDK9 jigsaw or is there some other 
> issue? If the former, then we need to solve a problem that isn't yet solved 
> with the build environment on our Hudson machines before this can go in.
> 
> 

Do you have the module-info.java.extra file loaded up?  It may be a build issue 
since that file is not exported by default.  Is this the same error we see when 
it doen't like the module boundaries?  do we need to add some -XaddExports?  It 
works for me, and the file is years old, so it may be order or operations 
issues with the JDK that is on the build server.

I'll look into building from a public EA build of Java 9 then (if I have time, 
Chris or Dmitry may get to do that). 

> 2) The JDK9_MODULES is a new variable that isn't currently defined. What 
> should it be set to? It looks like it is only used by the packagerDev task, 
> so might be OK.
> 

Right now it is for packagerdev, but going forward I see it being needed for 
the unit tests.

> 
> 3) The classesModuleExclude mechanism duplicates an existing mechanism to 
> filter out classes from going into the modules. Are you sure this new 
> mechanism is needed? After I fixed 
> https://bugs.openjdk.java.net/browse/JDK-8142381 
> <https://bugs.openjdk.java.net/browse/JDK-8142381> a couple weeks ago I no 
> longer see any classes from ant-javafx.jar showing up in the fxpackager 
> module.
> 

I'll look into removing that code then.


> -- Kevin
> 
> 
> Danno Ferrin wrote:
>> 
>> Here's the webrev: http://cr.openjdk.java.net/~shemnon/8080531/webrev.07/ 
>> <http://cr.openjdk.java.net/~shemnon/8080531/webrev.07/> 
>> <http://cr.openjdk.java.net/~shemnon/8080531/webrev.07/> 
>> <http://cr.openjdk.java.net/~shemnon/8080531/webrev.07/>
>> (it's been a stressful morning)
>> 
>>   
>>> On Nov 25, 2015, at 9:38 AM, Danno Ferrin  
>>> <mailto:danno.fer...@oracle.com> wrote:
>>> 
>>> Kevin, Chris, Dmitry
>>> 
>>> This is a bulk packager integration from the packager sandbox to the JavaFX 
>>> Sandbox, please review.
>>> 
>>> webrev: 
>>> 
>>> There are three changes outside of the fxpackager module that I think Kevin 
>>> needs to give his approval for.
>>> 
>>> Two changes are in the build.gradle.  The first adds a concept of 
>>> classesModuleExclude which is a regexp for files to exclude from the 
>>> modular jar. This is to support creating the ant jar outside of the module 
>>> system so that ant can read the required types and classes.
>>> 
>>> The second change is to introduce JDK9_MODULES, read off of an 
>>> environmental variable.  This should point to your jmods directory (not 
>>> explored modules, this must be jmods).  This is to support the packagerdev 
>>> target which now needs a pointer to the jmods which as of yet does not have 
>>> a standard location relative to the JDK/JRE.
>>> 
>>> The third change is the addition of another module-info.java.extra file.  
>>> This one exposes the invocation API for JDeps to packager so the 
>>> detectmodules can use it to sniff out modules from the classpath.
>>> 
>>> The remainder of the changes are internal to the fxpackager modules and 
>>> represent contributions from Chris Bensen, Dmitry Cherepanov, and myself 
>>> finishing out the last details for JEP275.  This patch should make it 
>>> feature complete (but not bug complete, we got another milestone for that).
>>> 
>>> --Danno
>>> 
>> 
>>   

Re: Bulk packager integration

[Danno Ferrin]

Here's the webrev: http://cr.openjdk.java.net/~shemnon/8080531/webrev.07/ 
<http://cr.openjdk.java.net/~shemnon/8080531/webrev.07/>
(it's been a stressful morning)

> On Nov 25, 2015, at 9:38 AM, Danno Ferrin  wrote:
> 
> Kevin, Chris, Dmitry
> 
> This is a bulk packager integration from the packager sandbox to the JavaFX 
> Sandbox, please review.
> 
> webrev: 
> 
> There are three changes outside of the fxpackager module that I think Kevin 
> needs to give his approval for.
> 
> Two changes are in the build.gradle.  The first adds a concept of 
> classesModuleExclude which is a regexp for files to exclude from the modular 
> jar. This is to support creating the ant jar outside of the module system so 
> that ant can read the required types and classes.
> 
> The second change is to introduce JDK9_MODULES, read off of an environmental 
> variable.  This should point to your jmods directory (not explored modules, 
> this must be jmods).  This is to support the packagerdev target which now 
> needs a pointer to the jmods which as of yet does not have a standard 
> location relative to the JDK/JRE.
> 
> The third change is the addition of another module-info.java.extra file.  
> This one exposes the invocation API for JDeps to packager so the 
> detectmodules can use it to sniff out modules from the classpath.
> 
> The remainder of the changes are internal to the fxpackager modules and 
> represent contributions from Chris Bensen, Dmitry Cherepanov, and myself 
> finishing out the last details for JEP275.  This patch should make it feature 
> complete (but not bug complete, we got another milestone for that).
> 
> --Danno

Bulk packager integration

[Danno Ferrin]

Kevin, Chris, Dmitry

This is a bulk packager integration from the packager sandbox to the JavaFX 
Sandbox, please review.

webrev: 

There are three changes outside of the fxpackager module that I think Kevin 
needs to give his approval for.

Two changes are in the build.gradle.  The first adds a concept of 
classesModuleExclude which is a regexp for files to exclude from the modular 
jar. This is to support creating the ant jar outside of the module system so 
that ant can read the required types and classes.

The second change is to introduce JDK9_MODULES, read off of an environmental 
variable.  This should point to your jmods directory (not explored modules, 
this must be jmods).  This is to support the packagerdev target which now needs 
a pointer to the jmods which as of yet does not have a standard location 
relative to the JDK/JRE.

The third change is the addition of another module-info.java.extra file.  This 
one exposes the invocation API for JDeps to packager so the detectmodules can 
use it to sniff out modules from the classpath.

The remainder of the changes are internal to the fxpackager modules and 
represent contributions from Chris Bensen, Dmitry Cherepanov, and myself 
finishing out the last details for JEP275.  This patch should make it feature 
complete (but not bug complete, we got another milestone for that).

--Danno

Re: Java 8 updates are causing "Apps that use non-public APIs will be rejected"

[Danno Ferrin]

We never remove it from a .dmg.  Only if it is a .pkg targeting the Mac App 
Store do we remove it.


> On Nov 17, 2015, at 3:57 PM, Stefan Fuchs  wrote:
> 
> Hi Kevin,
> 
> well, removing libjfxwebkit.dylib from dmg files would definitely break our 
> application, as we heavily rely on WebView.
> Our application is not distributed via Mac App Store, but as a download from 
> our website.
> 
> I think removing libjfxwebkit.dylib from the dmg should be an opt-in for 
> users, that want to upload their application to the Mac App Store.
> 
> Stefan
> 
> 
>> Yes, this is correct. We consider this only a short term workaround for the 
>> problem. A longer term solution will be needed that will allow distributing 
>> WebView applications.
>> 
>> Chris: is there a way to override this behavior?
>> 
>> -- Kevin
>> 
>> 
>> Dr. Michael Paus wrote:
>>> Just in order to better understand this issue and the fix. Does this mean 
>>> that the packager
>>> will now ALWAYS delete the libjfxwebkit.dylib when building a DMG file? 
>>> That would mean
>>> that I could not bundle and distribute any application anymore for the Mac 
>>> which uses
>>> a WebView. Have you considered the fact that many people do bundle their 
>>> apps but
>>> have their own distribution channels and do not upload the apps to the 
>>> Apple store.
>>> There should at least be some switch to override this behavior.
>>> Just my 2+1/2 cents.
>>> Michael
>>> 
>>> 
>>> 
>>> 
>>> Am 17.11.15 um 18:31 schrieb Kevin Rushforth:
 [taking awt-dev off of this thread]
 
 The fix that was put into 8u72-b02 is that the packager will no longer 
 include libjfxwebkit.dylib in the packaged app. Is this not working 
 correctly?
 
 -- Kevin
 
 
 Sergey Bylokhov wrote:
> I think openjfx-dev@openjdk.java.net (cc) is correct place to ask this 
> question.
> 
> On 16.11.15 23:10, Ondřej Kvasnovský wrote:
>> Hi,
>> 
>> We are facing to an issue with latest Java updates when we try to
>> release apps into Apple app store. I have described the issue here, with
>> all my findings:
>> http://ondrej-kvasnovsky.blogspot.com/2015/10/java-8-update-60-is-causing-apps-that.html
>>  
>> 
>> In short, the issue is that we are not able to release Java app into app
>> store since 1.8_60 because it uses private API (see the link above if
>> you want to know how to verify that).
>> 
>> I spoke about this issue with Martijn Verburg and he pointed me to these
>> two issues:
>> https://bugs.openjdk.java.net/browse/JDK-8138650 - fixed for 8u72
>> https://bugs.openjdk.java.net/browse/JDK-8138652 - permanent fix for 9
>> (replace private libs with public ones)
>> 
>> I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from
>> https://jdk8.java.net/download.html):
>> otool -L
>> /Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib
>>  
>> | grep icu
>> /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current
>> version 51.1.0)
>> And it the issue is still there, Build b05 still references private API.
>> 
>> I could even try to build and app and try to publish it for code review
>> by Apple... but since there is this reference, I do not believe it is
>> going to be successful.
>> 
>> Since this issue https://bugs.openjdk.java.net/browse/JDK-8138650 is
>> considered to be fixed, but it seems it is not, could someone help with
>> that?
>> 
>> 
>> Best wishes,
>> Ondrej Kvasnovsky
> 
> 
>>> 
>> 
> 

Re: Java 8 updates are causing "Apps that use non-public APIs will be rejected"

[Danno Ferrin]

Not for a DMG file, just .pkgs that are intended for the app store.

So .app, .dmg, and normal .pkgs will have unaltered jres.  The Mac App Store 
.pkgs will be made to conform to mac app store standards.

> On Nov 17, 2015, at 11:50 AM, Dr. Michael Paus  wrote:
> 
> Just in order to better understand this issue and the fix. Does this mean 
> that the packager
> will now ALWAYS delete the libjfxwebkit.dylib when building a DMG file? That 
> would mean
> that I could not bundle and distribute any application anymore for the Mac 
> which uses
> a WebView. Have you considered the fact that many people do bundle their apps 
> but
> have their own distribution channels and do not upload the apps to the Apple 
> store.
> There should at least be some switch to override this behavior.
> Just my 2+1/2 cents.
> Michael
> 
> 
> 
> 
> Am 17.11.15 um 18:31 schrieb Kevin Rushforth:
>> [taking awt-dev off of this thread]
>> 
>> The fix that was put into 8u72-b02 is that the packager will no longer 
>> include libjfxwebkit.dylib in the packaged app. Is this not working 
>> correctly?
>> 
>> -- Kevin
>> 
>> 
>> Sergey Bylokhov wrote:
>>> I think openjfx-dev@openjdk.java.net (cc) is correct place to ask this 
>>> question.
>>> 
>>> On 16.11.15 23:10, Ondřej Kvasnovský wrote:
 Hi,
 
 We are facing to an issue with latest Java updates when we try to
 release apps into Apple app store. I have described the issue here, with
 all my findings:
 http://ondrej-kvasnovsky.blogspot.com/2015/10/java-8-update-60-is-causing-apps-that.html
  
 
 In short, the issue is that we are not able to release Java app into app
 store since 1.8_60 because it uses private API (see the link above if
 you want to know how to verify that).
 
 I spoke about this issue with Martijn Verburg and he pointed me to these
 two issues:
 https://bugs.openjdk.java.net/browse/JDK-8138650 - fixed for 8u72
 https://bugs.openjdk.java.net/browse/JDK-8138652 - permanent fix for 9
 (replace private libs with public ones)
 
 I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from
 https://jdk8.java.net/download.html):
 otool -L
 /Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib
  
 | grep icu
 /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current
 version 51.1.0)
 And it the issue is still there, Build b05 still references private API.
 
 I could even try to build and app and try to publish it for code review
 by Apple... but since there is this reference, I do not believe it is
 going to be successful.
 
 Since this issue https://bugs.openjdk.java.net/browse/JDK-8138650 is
 considered to be fixed, but it seems it is not, could someone help with
 that?
 
 
 Best wishes,
 Ondrej Kvasnovsky
>>> 
>>> 
> 

Re: Followup on our Splash Screen discussion at JavaOne (using AWT-SplashScreen)

[Danno Ferrin]

This is a known issue and is being tracked with JDK-8090606.

https://bugs.openjdk.java.net/browse/JDK-8090606 


> On Nov 11, 2015, at 3:24 AM, Tom Schindl  wrote:
> 
> Hi Chris, Danno and OpenJFX-Group,
> 
> Chris not sure you remember our discussion at JavaOne concerning a
> static splash that opens when using the java-packager.
> 
> You said you think the AWT-Splash should work so I gave that a try today
> and in general AWT-Splash and JavaFX can be used together if you:
> a) start with java -jar 
> b) start with java -splash:
> 
> but it does not work with the java-packager :-(
> 
> I've package up a sample application demonstrating showing the problem
> and uploaded it to drop box
> https://www.dropbox.com/s/6rtzmfdojqfoihh/TestSplash.zip?dl=0
> 
> Correct me if wrong but not supporting the AWT-Splash with java-packager
> is certainly a bug because one should be able to ship eg swing
> applications as well who might have used the AWT-Splash as well.
> 
> Certainly AWT-Splash is fine with Java8 but for Java9 I would have to
> ship AWT with my application just to use the splash which a none started
> so my wish for Java9 would be if the packager would support opening a
> *static* splash-image and providing me a none AWT-bound API to bring it
> down.
> 
> Tom
> 
> -- 
> Thomas Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
> http://www.bestsolution.at/
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

[sandbox-9-jake] Review Request 8080531 - fix ant-javafx ant tasks

[Danno Ferrin]

Kevin, Chris, Dmitry
Because of the way resources are being handled in current revs of Jake we 
need to pull the main ant task classes back into ant-javafx and not deploy them 
into the main packager module.  Properly exported in module-info.java all of 
the other classes are just fine.  It touches the build.gradle hence the need 
for Kevin's vote.

This patch adds the notion of a set of classes to exclude from the generated 
module.  FXPackager then excludes the ant classes from the module and makes 
sure those are the only classes included in ant-javafx.jar.  Fairly 
straightforward (for once).  

webrev: http://cr.openjdk.java.net/~shemnon/8080531/webrev.05/ 

supporting jira: https://bugs.openjdk.java.net/browse/JDK-8080531 

[9-sandbox-jake] Request for Approval - 8080531 - Modular Java Application Packaging

[Danno Ferrin]

Kevin, Chris,

This is a Work in Progress to be put in the jake sandbox for JEP-275 work.  
Mostly so we can get it out in the open before JavaOne at the end of the month. 
 

This patch breaks the deployment samples, and there isn't a plan in place to 
fix them.  The issues are deep and relate to Ant.

This patch requires JDK9_HOME to be set to a current jigsaw build.  So current 
you have to sync as of 12 Oct or later because some of the JLink APIs are also 
a work in progress.  If you don't set JDK9_HOME then the packager won't be 
built at all.  The previous webrevs use the older APIs.

Only Mac has received much in the way of testing.  And then only the most basic 
testing since Gradle for the foreseeable future cannot run the unit tests on 
Java 9 (this is a problem with Gradle).

webrev: http://cr.openjdk.java.net/~shemnon/8080531/webrev.04/ 

jira: https://bugs.openjdk.java.net/browse/JDK-8080531 

Re: Windows Store App Package Enhancment

[Danno Ferrin]

> On Oct 7, 2015, at 1:22 PM, Scott Selvia  wrote:
> 
> I would like to request an enhancement to have the packager support a Windows 
> Store application bundle as it currently supports the Mac App store package 
> process.
> 
> I ask this question without checking the code availability, is the packager 
> code open sourced for others to contribute? 

The source code is all GPL+Classpath:

The current released code is http://hg.openjdk.java.net/openjfx/8u-dev/rt/ 
 and the main packager bits are 
here 
http://hg.openjdk.java.net/openjfx/8u-dev/rt/file/761213753af4/modules/fxpackager
 
.
  I'm working on some jigsaw updates and the will be here when ready: 
http://hg.openjdk.java.net/openjfx/sandbox-9-jake/ 



>  It would be really nice to automate the windows store code process, it is 
> not that dissimilar (makeappx, having an appxmanifest.xml (aka entitlements), 
> sign tool, etc..)

The main problem is a very basic on.  I haven't checked the Windows 10 store, 
but in the windows 8 and Windows 8.1 timeframe all windows app store apps had 
to be WinRT applications, and Java is Win32.  I think WinRT has been re-named 
to be Universal Applications.

The problem is very deep, however.  One of the key constraints of WinRT was 
that like iOS you were prohibited from generating code and running it from the 
same app.  (technically you couldn't flip the NX bit on any pages to change 
them from data to code).  This is Java and the HotSpot VM's modus operandi, to 
take java byte code, create native code, and flip the MX bit.  It can run in 
all-interpreted mode but that is orders of magnitude slower.

So there is a whole lot more to a windows store installer than looks like 
initially, and it has little to do with packaging. 

--Danno

Re: Windows 8 Store / Windows 10 Store

[Danno Ferrin]

To publish the app itself, no, not right now.  The core issue is that the Java 
Runtime is not a WinRT/Win10 app but is still a win32 app, and they don’t 
publish those in their store.  Since that is not my area of expertise, I don’t 
know about plans relating to WinRT/Win10 APIs.  The core OpenJDK lists may be a 
better place to float that question.  But even then, that is just the first 
step.

The best you can do is get a store page and publish a link that holds your 
installer.  That’s what lots of Win32 apps do currently.  This also contributes 
to why the Windows App Store is relatively unsuccessful compared to other app 
stores. (the fact there are viable non-app store alternatives is the biggest 
issue IMHO).

> On Sep 17, 2015, at 3:36 AM, Däbritz, Martin  
> wrote:
> 
> Hey,
> 
> I want to know if there is a way to publish an application on Windows 8 / 10 
> Store, which is written with JavaFX?
> 
> Kind regards,
> 
> Martin Siegfried Däbritz

Re: JavaFX Self-contained PKG and MacAppStore_PKG did not work

[Danno Ferrin]

Mac installer is weird.  The install location in the installer is at best a 
strongly worded suggestion to the pkgutil code and I don't completely 
understand when it follows it and when it doesn't.

What I have seen in my development is that if the package has been installed 
and or run anywhere else on the machine then the pkgutil will install the app 
into that location as an update to the existing application.  So in my case I 
had an instance of the app that I had run from my source control build 
directory, and pkgutil chose to update that instance of the application rather 
than one I had in /Applicaitons that I drug in from a DMG.

It appears that this is driven by the CFBundleIdentifier, so changing the 
identifier may get a clean install.

Running  pkgutil --pkg-info  may tell you where it is installed or where 
it thinks it is installed.


> On Aug 7, 2015, at 9:11 PM, Tai Hu  wrote:
> 
> Hi,
> I used JavaFX ant tasks to create all native packages on Mac OS X (JDK 
> 8u51 on latest Mac OS X). Both .app and .dmg packages are working flawlessly. 
> However, for PKG package, the very first installation was successful and my 
> application show up in /Applications folder. However, if I delete my app from 
> /Applications and use PKG package to install again, the installation process 
> will always run successfully. However, my application did not show up inside 
> of /Applications. I already tried to use pkgutil —forget  and 
> rebooted my Mac. It is still the same result. Installation of PKG package are 
> always successful. But my application is not installed under /Applications 
> folder.
> 
> Thanks,
> 
> Tai

Re: Can we use JavaPackager and a get full JRE?

[Danno Ferrin]

> On Aug 8, 2015, at 5:16 PM, Scott Palmer  wrote:
> 
> I’m using the JavaFX gradle plugin to build a very simple application with 
> the new java packager and I’ve noticed a problem with the embedded JRE, at 
> least on OS X.
> 
> Specifically, the ‘bin’ folder is missing from the embedded JRE, presumably 
> because the embedded launcher replaces it.

We deliberately strip that folder from the package.  The functionality provided 
by the launcher is not equivalent and is only sufficient to support application 
launch.  The goal is to have a JRE embedded just for the application, and 
leaving the bin folder leaves entry points for non-embeded use of the JRE.

> However my application (and many others) needs to launch a new java process.  
> Part of the reason for doing so is so it can be launched with new JVM options 
> that are determined at runtime.  For example modifying the java.library.dir 
> after finding “plugins” that have native code.
> 
> Now it fails when running from the app bundle (works fine from a command 
> line).  The problems is that it fails to launch a new ‘java’ process because 
> it expects to find 'bin/java' in the JRE folder.
> 
> What is the solution?

It's not easy, since this is functionality that is deliberately removed in the 
name of security.  You could copy the .../bin/java file somewhere else prior to 
packaging and then copy it back into place after packaging, but that would be 
platform specific.

> 
> Since I’m using Gradle, I’m thinking I could tweak things to copy the JRE bin 
> folder into the .app/Contents/PlugIns/Java.runtime/Contents/Home/jre/ 
> folder,


This would be very difficult to accomplish with the current gradle plugin.  
It's an unconventional step and hence the plugin makes unconventional stuff 
difficult unless hand wired soup to nuts.

> but really the javapackager should have an option to include the “full” JRE.


I haven't seen how the bugs.openjdk.java.net  
transition has affectied it, but in the JIRA days I would say open a JIRA and 
we can add it to our feature queue.  But this would have an additional step of 
going through a security audit (since the removal was deliberate for security) 
and the security engineers may not be cool with it (then again, if it is a non 
default option they may accept it), so it's not a slam dunk.

> 
> Or perhaps we need a new API in Java 9 to support launching a new Java 
> process?
> 

Officially it's not too late to get new features such as this into the 9.0 
release, but unless it is related to the module system and making it work 
somehow my thoughts are that it won't get accepted into 9.0.

> 
> Regards,
> 
> Scott
> 
> 

Re: How to Include a License File in Self-Contained Application Package

[Danno Ferrin]

Currently the Mac App Store support for java packager does not support a 
click-through license.  One could be added if a web-bug feature request was 
posted, and we could add it to the queue.  We do support click-through licenses 
for .DMG and .PKG distributions on mac, just not MAS right now.

Right now we only use synthesized distribution.xml files created by 
productbuild and don't create our own, this is much more resilient to the OS 
changing underneath us.

--Danno

> On Aug 6, 2015, at 2:11 PM, Tai Hu  wrote:
> 
> Hi all,
> I am preparing our product (built in JavaFX 8) for submission to Apple 
> Mac Store. All code signing and self-contained installer generation are done. 
> However, I couldn’t figure out how I could add our license file into pkg 
> package, which will show the end user before installation. Based on JavaFX 8 
> deployment document, this could be done by using drop in resources. I could 
> find any more details or sample online. Could anyone point me to a right 
> direction? 
> 
> Thanks,
> 
> Tai

Re: slightly ot: java9 runtime images

[Danno Ferrin]

I think what Tom was alluding to was an all in one executable that contains all 
the data in one file.  What the "Windows Application Image" creates is a 
directory that contains all the jars, the JRE, and the executable that launches 
the whole setup.

If an all in one executable is something you think will be generally valuable, 
please let you Oracle Sales rep know so they can pass it down to the PM group 
so we can get it on the radar.

> On May 13, 2015, at 4:19 AM, Benjamin Gudehus  wrote:
> 
> Hi Tom!
> 
> >I would really like to be able to generate such a standalone exe.
> 
> With Danno's javafx-gradle Gradle plugin and with the java package API 
> (com.oracle.tools.packager.Bundler from Java 8) it is possible to generate a 
> standalone exe without installer (the bundler name is "Windows Application 
> Image"). That's the first thing I noticed, when I tested it.
> 
> Regards,
> Benjamin
> 
> On Wed, May 13, 2015 at 11:43 AM, Tom Eugelink  <mailto:t...@tbee.org>> wrote:
> On 7-5-2015 15:52, Danno Ferrin wrote:
> It would be a major improvement (not only for JavaFX applications, but also 
> standalone servers) if it would become possible to create a truly single 
> distributable, without having to repack the jars. So either by automatic 
> unpacking to a tmp and setting the classpath prior to stating java (cleaning 
> up afterwards), or allowing jars-in-jars or jars-in-distributable.
> 
> In 8u40 we added an option to install your application as service or daemon, 
> so you can use the java packager to install your microsoervices.
> 
> 
> I've spent some time with the JavaFX packager (though the 
> javafx-maven-plugin) and I am able to generate:
> - a distribution in the form of a lib directory and entry point jar
> - an exe & msi that are both installers
> 
> What I am not able to generate is an exe that can simply be started. Right 
> now my distribution consist of an all-in-one jar (jars-in-a-jar) that can 
> simply be started. The JRE is also simply copied (when not present), so there 
> is no need to install anything, just copy and start. I would really like to 
> be able to generate such a standalone exe. Is this a limitation of the plugin 
> or the packager? Since the plugin seems to be very close to the packager, I'm 
> thinking the latter.
> 
> Tom
> 
> 
> 

Re: slightly ot: java9 runtime images

[Danno Ferrin]

I looked at the man pages, and it’s not there.  That is strange because I 
remember working with the docs people to get them the info they needed.

The best docs are from my JavaOne presentation:  
https://oracleus.activeevents.com/2014/connect/fileDownload/session/3B139AAF656DC1741328669FE873981E/CON2247_Ferrin-8u20%20packager.pdf
 


As far as java callbacks… the support is fairly basic at the moment.  You own 
the JVM w/o a security sandbox so you can add standard shutdown hooks as well 
as other libraries that react to unix signals.  Signals are non-standard as the 
current Java signal classes exist in sun.misc.*, hence they an internal API and 
will not be accessible in JDK 9 (without contortions).

For windows a custom service executable is created.
For Linux init.d scripts are added.
For Mac launchd is used.

> On May 7, 2015, at 8:04 AM, Tom Schindl  wrote:
> 
> [...]
> 
>> In 8u40 we added an option to install your application as service or daemon, 
>> so you can use the java packager to install your microsoervices.
>> 
> 
> [offtopic]
> 
> Interesting where is this documented - google did not show up any
> results? Do I get callbacks in my Java code to react on a shutdown request?
> 
> Tom
> 
> -- 
> Thomas Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
> http://www.bestsolution.at/
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

Re: slightly ot: java9 runtime images

[Danno Ferrin]

> On May 7, 2015, at 6:27 AM, Tom Eugelink  wrote:
> 
> On 7-5-2015 02:15, Danno Ferrin wrote:
>> You can already do some of that today with Java 8 and the Java Packager.  
>> You can create a file tree that can be zipped up that includes the runtime 
>> and all of the application files, as well as native installers for windows, 
>> linux, and mac that will install this file tree (or “image”).
>> 
>> We haven’t announced many public plans for Java 9 yet (since many parts are 
>> still TBD) so I cannot comment on how jigsaw and java packager will 
>> integrate, but I would expect that they will work together in some fashion.
>> 
> 
> From all the documentation I find, I understand that even though with Java 
> packager you can create an executable including the (required parts of the) 
> JVM, you still need to unpack and repack all the jars into a single jar. This 
> has the problem of breaking signed jars. Classloader based solutions like 
> onejar get into all kind of conflicts with possible other classloaders in the 
> application.
> 

I don’t know where you got your information, it has never been the case for as 
long as i’ve used it and worked on it before my employ at Oracle that you have 
to rely on a single jar for Java Packager.  Repacking jars is completely 
unneeded and the Java Packager takes the library jars you provide without 
alteration, preserving external signatures and structure essential to stuff 
like OSGi.  

In fact, you can provide assets that are not jars and you can set the class 
path to only include certain jars, no need to unpack jars at runtime.


> It would be a major improvement (not only for JavaFX applications, but also 
> standalone servers) if it would become possible to create a truly single 
> distributable, without having to repack the jars. So either by automatic 
> unpacking to a tmp and setting the classpath prior to stating java (cleaning 
> up afterwards), or allowing jars-in-jars or jars-in-distributable.
> 

In 8u40 we added an option to install your application as service or daemon, so 
you can use the java packager to install your microsoervices.

Re: slightly ot: java9 runtime images

[Danno Ferrin]

> On May 6, 2015, at 5:39 PM, Michał Zegan  wrote:
> 
> Hello.
> 
> Sorry for asking it here, but I have too many lists I subscribed to
> and I don't want to join a new one just to ask this one question:
> I heard that java9 will (or might) make it possible to create a
> runtime image of an application consisting of all modules that it
> needs including parts of the standard library, and also the virtual
> machine.

What you are describing is the Jigsaw project, which has been demoed at several 
JavaOnes.  Some of the process bits can be found on this website: 
http://openjdk.java.net/projects/jigsaw/ 

> If what I've heard is right, what form will those images have?

Right now it looks suspiciously similar to what a Java 8 runtime image looks 
like.  But there are already some major differences.  JEP 201 and JEP 220 cover 
most of those changes at the moment.

> executable programs, or zip/tar/whatever archives containing all
> components, or native installers?

You can already do some of that today with Java 8 and the Java Packager.  You 
can create a file tree that can be zipped up that includes the runtime and all 
of the application files, as well as native installers for windows, linux, and 
mac that will install this file tree (or “image”).  

We haven’t announced many public plans for Java 9 yet (since many parts are 
still TBD) so I cannot comment on how jigsaw and java packager will integrate, 
but I would expect that they will work together in some fashion.

RT-40554: On Mac, application created by javapackager can not run.

[Danno Ferrin]

Kevin, Chris
Please review for inclusion in b12

webrev: http://cr.openjdk.java.net/~shemnon/RT-40554/webrev.01/ 

Bug: RT-40554: On Mac, application created by javapackager can not run.

Re: Private APIs not usable in Java 9?

[Danno Ferrin]

Just adding to the comment that a specific user has the issue will help, 
especially when it comes to validating the fix.

> On Apr 8, 2015, at 2:24 PM, Hervé Girod  wrote:
> 
> Do you need a specific classification for such JIRAs?
> 
> Sent from my iPhone
> 
>> On Apr 8, 2015, at 22:05, Danno Ferrin  wrote:
>> 
>> 
>>> On Apr 8, 2015, at 1:52 PM, Robert Krüger  wrote:
>>> our only workaround is to use private API
>> 
>> For the benefit of the devs on the list, could you please point out what 
>> private APIs you currently need to use?  That way we can make sure proper 
>> JIRAs are filed and we can connect those to actual real-world problems.

Re: Private APIs not usable in Java 9?

[Danno Ferrin]

> On Apr 8, 2015, at 1:52 PM, Robert Krüger  wrote:
>  our only workaround is to use private API 

For the benefit of the devs on the list, could you please point out what 
private APIs you currently need to use?  That way we can make sure proper JIRAs 
are filed and we can connect those to actual real-world problems.

Review Request: RT-39975 - AppCDS support for packager

[Danno Ferrin]

Kevin, Chris, please review

jira: https://javafx-jira.kenai.com/browse/RT-39975
webrev: http://cr.openjdk.java.net/~shemnon/RT-39975/webrev.00/

Re: Packaging a JFX app in a gradle build system

[Danno Ferrin]

Yes, bitbucket is the main repo, github is a mirror (currently out of date).

(sorry for the late response, just got back from a long spring break).

> On Mar 28, 2015, at 9:30 AM, Scott Palmer  wrote:
> 
> I believe the bitbucket repo is the main page. At least the bintray page 
> points to it.
> 
> Scott
> 
> On Mar 28, 2015, at 11:10 AM, Robert Krüger  > wrote:
> 
>> Which repository is the master? Bitbucket or github? I just saw a posting by 
>> someone mentioning that it is also on github.
>> 
>> On Fri, Mar 27, 2015 at 7:27 AM, Robert Krüger > > wrote:
>> On Fri, Mar 27, 2015 at 12:16 AM, Scott Palmer > > wrote:
>> I am successfully using the javafx gradle plugin to produce a packaged app 
>> on Windows and Linux. (Thanks Danno!)
>> I haven't tried much with Mac yet, but I believe it will make an application 
>> bundle.
>> 
>> 
>> That sounds great. I will give it a try on OSX then.
>>  
>> Oracle should be making this part of your day job, Danno.  Who do I need to 
>> bribe? :-)
>> 
>> 
>> Absolutely! Easy packaging (i.e. well integrated into a build process), 
>> especially if it's cross-platform, is a big thing to make JavaFX more 
>> attractive to developers. 
>> 
>> 
>> 
>> -- 
>> Robert Krüger
>> Managing Partner
>> Lesspain GmbH & Co. KG
>> 
>> www.lesspain-software.com 

Re: Packaging a JFX app in a gradle build system

[Danno Ferrin]

It’s not abandoned, I’ve just had a lot of work on my day job at the moment.

For 8u20 and later you can access most of the new features from the builder 
arguments.  Secondary launchers and file associations will require some 
additions I hope to get to in the next month or so.

> On Mar 26, 2015, at 10:36 AM, Robert Krüger  wrote:
> 
> Hi,
> 
> sorry for posting this here but I have tried Stackoverflow and the Oracle
> JFX user forum first with no responses.
> 
> I am looking for the most sensible way to integrate packaging of a JavaFX
> application into my Gradle build.
> 
> The plugin at https://bitbucket.org/shemnon/javafx-gradle does not look
> like it's maintained and I was wondering if there was a better way than
> manually hacking together a command line invocation of javapackager where I
> have to manually resolve all the dependency stuff myself.
> 
> For OSX packaging I have successfully played around with the gradle plugin
> at https://code.google.com/p/gradle-macappbundle/, which offers the level
> of convenience that I am looking for but I thought this was something that
> was within the scope of the Javapackager shipped with the JDK, which I
> would like to use, mainly because it is a supported/maintained piece of
> software and supports more than just OSX.
> 
> Any advice from people doing similar things or maybe the
> Javapackager-Developers?
> 
> Best regards,
> 
> Robert

Re: Error creating bundle for MacOSX using u40 b23

[Danno Ferrin]

Sorry for the late response.  Comcast decided monday at 2pm was the correct 
time to upgrade some cable hardware for the whole neighborhood.  Because 
comcast cares.

My guess is it's failing to find a key for one reason or another.  Perhaps the 
keys aren't unlocked, or they are named slightly differently than the defaults, 
or there are multiples with the same prefix.  Running the bundler in verbose 
mode should tell you.

There are bundler arguments to fine tune the key selection.

The Mac PKG bundler looks for a key starting with "Developer ID Installer: " by 
default, and fails if it finds more than one.  You can refine the search by 
setting "mac.signing-key-user-name" to whatever comes after the prefix if there 
are multiple hits, or set the entire pkg sigining key by setting 
"mac.signing-key-developer-id-installer".

For the .app bundler the same thing exists except the prefix is "Developer ID 
Application: " and the whole key name is set via 
"mac.signing-key-developer-id-app"  The user name via the user name key is the 
same as before, and it applies to all mac keys.

For the Mac App Store bundler the prefixes it looks for are "3rd Party Mac 
Developer Application: " and "3rd Party Mac Developer Installer: " for the app 
and the .pkg fiiles respectively, and the whole key names can be set with 
"mac.signing-key-app" and "mac.signing-key-pkg" respectively.

Hopefully that helps.


On Feb 2, 2015, at 4:25 PM, Tony Anecito  wrote:

> Hi All,I looked over the text when the deploxfx is run and all I see is the 
> installer certificate being used and never the developer release certificate. 
> the .app never gets signed with anything except with something called Mach-0 
> thin (x86-64). Regards,-Tony  
> 
> On Monday, February 2, 2015 3:30 PM, Tony Anecito  
> wrote:
> 
> 
> Hi All,Ok. It seems to be working now for some reason. Now I have yet another 
> new issue. Seems when I submit via application loader 3.0 I get a error about 
> the code object not being signed at all and to make sure I used a 
> distribution certificate. When I used to do this manually not using deployfx 
> supplied with jdk I had to sign the pkg with a ceritificate and never had 
> this issue. Is this a new issue with u40 b23?Any ideas how to fix this? 
> Thanks,-Tony  
> 
> On Monday, February 2, 2015 2:07 PM, Tony Anecito  
> wrote:
> 
> 
> 
> Hi All, I tried using u40 b23 to create my macosx pkg file. I am getting the 
> error:execution error: Finder got an error: Can't set toolbar to visible of 
> container window of disk "app title" to false. (-10006) Then slightly later 
> during the build got the BUILD FAILED. This worked fine for u20 when I last 
> tried it. Thanks for any hints.-Tony
> 
> 
> 
> 

Re: Why do the Linux packages go into /opt?

[Danno Ferrin]

I'm not sure why it goes into /opt (that decision predates my tenure), but 
since the JRE is included it may be considered a "large software package" 
unsuitable for the /usr directory, and since it is an "add-on application 
software packages" opt seems to be a sensible place.  It may also be a solaris 
thing that leaked into the thought process.  These packages also were designed 
to be launched from within a desktop shell, so being on the path was less of an 
issue.

For 8u40 and earlier it is in fact hard coded in the generation of the 
supporting files for RPM and DEBs.  Based on my reading that could be made 
configurable, at least at time of packaging.  If you submitted a JIRA we could 
get that in for 8u60, but the new feature/new bug window for 8u40 is mostly 
closed.  However the structure underneath the package is a larger item to mess 
around with, so it would merely be a pointer to a different directory to 
install it in as opposed to placing bits widely across the system. 

Perhaps a step in the package that adds a link to /usr/bin in the control file 
or install scripts may be a better solution.

On Jan 27, 2015, at 1:29 PM, Mike Hearn  wrote:

> javapackager makes debs that install things into /opt, which means they
> aren't on the path. Is there a reason for this choice rather than making
> FHS-compliant packages that install into /usr?
> 
> thanks!

Re: How to handle file open requests on MacOS

[Danno Ferrin]

set the exe to install "System Wide" .. -Bwin.exe.systemWide=true via the CLI.  
This will cause the application to be installed with admin privleges.

Can you open a bug for this (just cut and paste the e-mail) so it will work for 
local installs?

On Jan 5, 2015, at 1:09 PM, Mike Hearn  wrote:

> OK, then I might switch (or maybe not, as my current solution works ...)
> 
> BTW I noticed that the javapacker ISS changes put the file association 
> entries into HKEY_CLASSES_ROOT. Doing this results in an error half way 
> through setup if you don't run the installer with admin privs. The current 
> installer setup runs just fine with lowest privs, so it'd be perhaps nicer to 
> put the registry entries under HKEY_CURRENT_USER\SOFTWARE\Classes instead:
> 
> http://support.microsoft.com/kb/257592
> 
> On Mon, Jan 5, 2015 at 8:59 PM, Danno Ferrin  wrote:
> This code works inside of a JavaFX application too, just tried it locally.  
> 
> You may be thinking of an older iteration of the apple application listener 
> classes or perhaps the native level of the code.
> 
> On Jan 5, 2015, at 11:04 AM, Mike Hearn  wrote:
> 
>> Scene Builder doesn't do it this way - AFAICT you're only allowed to have 
>> one such event handler registered with the OS and JavaFX already registers 
>> one ... it just doesn't expose the resulting Java events via public API.
>> 
>> On Mon, Jan 5, 2015 at 6:50 PM, Danno Ferrin  wrote:
>> Oh, yes.  Mac has it's own Applicaiton class.  Here's the imports for the 
>> second file...
>> 
>> import com.apple.eawt.AppEvent;
>> import com.apple.eawt.Application;
>> import java.io.File;
>> import java.util.List;
>> import javax.swing.SwingUtilities;
>> 
>> The com.apple.eawt stuff is shipped with Oracle JRE and JDK, but like I said 
>> in my previous mail you need to pass a flag to the compiler to turn off it's 
>> index and read the jar.
>> 
>> The JavaDoc has gone MIA though -- 
>> https://bugs.openjdk.java.net/browse/JDK-8027638 but you can peruse the 
>> source code to see the details, it's all OpenJDK - 
>> http://hg.openjdk.java.net/jdk8u/jdk8u40/jdk/file/564bca490631/src/macosx/classes/com/apple/eawt
>> 
>> On Jan 5, 2015, at 10:43 AM, Mike Hearn  wrote:
>> 
>> > What is Application.getApplication() here? The JavaFX Application class 
>> > does not have a setOpenFileHandler method. Is that a Mac-specific API?
>> >
>> > It's too bad that 8u40 won't have this. Being able to easily open double 
>> > clicked files is pretty basic. Perhaps post 8u40 the JFX team could go 
>> > through Scene Builder and identify everywhere it relies on internal APIs 
>> > or custom magic and suck it into the core API, as then you'd have 
>> > confidence that an app of real complexity can be done entirely with 
>> > documented stuff.
>> 
>> 
> 
> 

Re: How to handle file open requests on MacOS

[Danno Ferrin]

This code works inside of a JavaFX application too, just tried it locally.  

You may be thinking of an older iteration of the apple application listener 
classes or perhaps the native level of the code.

On Jan 5, 2015, at 11:04 AM, Mike Hearn  wrote:

> Scene Builder doesn't do it this way - AFAICT you're only allowed to have one 
> such event handler registered with the OS and JavaFX already registers one 
> ... it just doesn't expose the resulting Java events via public API.
> 
> On Mon, Jan 5, 2015 at 6:50 PM, Danno Ferrin  wrote:
> Oh, yes.  Mac has it's own Applicaiton class.  Here's the imports for the 
> second file...
> 
> import com.apple.eawt.AppEvent;
> import com.apple.eawt.Application;
> import java.io.File;
> import java.util.List;
> import javax.swing.SwingUtilities;
> 
> The com.apple.eawt stuff is shipped with Oracle JRE and JDK, but like I said 
> in my previous mail you need to pass a flag to the compiler to turn off it's 
> index and read the jar.
> 
> The JavaDoc has gone MIA though -- 
> https://bugs.openjdk.java.net/browse/JDK-8027638 but you can peruse the 
> source code to see the details, it's all OpenJDK - 
> http://hg.openjdk.java.net/jdk8u/jdk8u40/jdk/file/564bca490631/src/macosx/classes/com/apple/eawt
> 
> On Jan 5, 2015, at 10:43 AM, Mike Hearn  wrote:
> 
> > What is Application.getApplication() here? The JavaFX Application class 
> > does not have a setOpenFileHandler method. Is that a Mac-specific API?
> >
> > It's too bad that 8u40 won't have this. Being able to easily open double 
> > clicked files is pretty basic. Perhaps post 8u40 the JFX team could go 
> > through Scene Builder and identify everywhere it relies on internal APIs or 
> > custom magic and suck it into the core API, as then you'd have confidence 
> > that an app of real complexity can be done entirely with documented stuff.
> 
> 

Re: How to handle file open requests on MacOS

[Danno Ferrin]

Oh, yes.  Mac has it's own Applicaiton class.  Here's the imports for the 
second file...

import com.apple.eawt.AppEvent;
import com.apple.eawt.Application;
import java.io.File;
import java.util.List;
import javax.swing.SwingUtilities;

The com.apple.eawt stuff is shipped with Oracle JRE and JDK, but like I said in 
my previous mail you need to pass a flag to the compiler to turn off it's index 
and read the jar.

The JavaDoc has gone MIA though -- 
https://bugs.openjdk.java.net/browse/JDK-8027638 but you can peruse the source 
code to see the details, it's all OpenJDK - 
http://hg.openjdk.java.net/jdk8u/jdk8u40/jdk/file/564bca490631/src/macosx/classes/com/apple/eawt

On Jan 5, 2015, at 10:43 AM, Mike Hearn  wrote:

> What is Application.getApplication() here? The JavaFX Application class does 
> not have a setOpenFileHandler method. Is that a Mac-specific API?
> 
> It's too bad that 8u40 won't have this. Being able to easily open double 
> clicked files is pretty basic. Perhaps post 8u40 the JFX team could go 
> through Scene Builder and identify everywhere it relies on internal APIs or 
> custom magic and suck it into the core API, as then you'd have confidence 
> that an app of real complexity can be done entirely with documented stuff.

Re: How to handle file open requests on MacOS

[Danno Ferrin]

On Jan 5, 2015, at 10:07 AM, Mike Hearn  wrote:

> 8u40 has javapackager improvements to help you do file associations in your
> installers. I'm looking forward to this, though for now I have to do it
> manually with 8u20.
> 
> But one problem I've found is that just setting up the file associations is
> not enough. You must handle the "openFile" messages sent by the OS as well.
> On Linux/Windows the interface is simple: the OS starts another copy of
> your app with the command line parameter. On MacOS you get a message posted
> to your message queue because apps are single instance by default. To
> handle this in JFX we must use internal APIs, like in the code snippet
> below.
> 
> Hopefully 8u40 will contain a proper cross platform file open request API
> that exposes this in a better way, otherwise the new javapackager support
> will be rather hard to use.

8u40 will not contain such an API, what is in 8u40 is what is visible in the EA 
releases.  Only major bugs will be fixed at this point.

For a demo proof of concept application I settled on a "two main" solution.  
One main is for the Mac and one is for Win/Linux.  The win/linux main was the 
principal main class:

(warning: the demo was swing based, avert your eyes)

public class MainApplication {

/*  */

void loadFile(File f) {
/*  */
}

/*  */

public static void main(String [] args) {
SwingUtilities.invokeLater(() -> { // My Eyes!  The Goggles, they do 
nothing!
MainApplication app = new MainApplication();
app.createGUI();
if (args.length > 0) {
File f = new File(args[0]);
if (f.isFile()) {
app.loadFile(f);
}
}
});
}
}

The gist is that the main delegates to a load file method in the normal main, 
and the app has a stable state outside of the loaded file.

For Mac I wrote a MainApplicationMac that did mac-isms (not masochisms) in a 
different main method.  It extended strictly for method accessibility.

public class MainApplicationMac extends MainApplication {

public static void main(String[] args) {
SwingUtilities.invokeLater(() -> {
MainApplication app = new MainApplication();
app.createGUI();
if (args.length > 0) {
File f = new File(args[0]);
if (f.isFile()) {
app.loadFile(f);
}
}


Application.getApplication().setOpenFileHandler((AppEvent.OpenFilesEvent ofe) 
-> {
List files = ofe.getFiles();
if (files != null && files.size() > 0) {
app.loadFile(files.get(0));
}
});

});
}
}

Really the only new code is the second block.

Also since I segregated out the mac stuff I did build gymnastics to ensure this 
is only built and packaged on a mac, so the introspection isn't done.  But I 
did have to add "-XDignore.symbol.file=true" to the javac arguments since the 
mac specific classes are not added to the symbol file for some odd reason.

Another thing you will notice that is different from mac and win/linux is that 
the same application receives all file open requests, whereas in win/linux you 
will see a new application opened for each request.

[8u40] review request: RT-39733 - Packaging with a JRE as installed fails codesign on OSX 10.9.5 or 10.10

[Danno Ferrin]

Kevin, David, please review

JIRA: https://javafx-jira.kenai.com/browse/RT-39733
Webrev: http://cr.openjdk.java.net/~shemnon/RT-39733/webrev.00/

Current Webrev is against 8u-dev , I'll get one against 8u40 soonish.

Review Request

[Danno Ferrin]

Kevin, please review:

Jira: https://javafx-jira.kenai.com/browse/RT-39634
Webrev: http://cr.openjdk.java.net/~shemnon/RT-39634/webrev.01/

Even though the impact is strictly cosmetic, I consider this critical for 8u40. 
 The code added is seen elsewhere in other bundlers and is being replicated at 
an earlier location.

--Danno

Re: 8U40 b16 support for command line arguments for JavaFX Deploy...

[Danno Ferrin]

Not sure what you mean by deployfx.   My google-fu comes up with devops stugg.

We support default command line arguments in 8u40.  i.e. if you launch just 
from the icon launcher we can supply some command line arguments.

For ant it is the  element underneath the  
datatype.

for bundler arguments, it is the "arguments" argument which is a List, 
and if a plain old string is passed in it is whitespace delimited (with no 
escapes).

On Dec 8, 2014, at 11:06 AM, Tony Anecito  wrote:

> Hi Danno,
> 
> Does 8u40 b16 support DeployFX java command line arguments? I brought this up 
> some time ago and you said it would be in 8u40.
> Also, what ant tags would I use for it?
> 
> Thanks,
> -Tony

Review Request: RT-36851 - preloaders don't work in packaged applicaitons

[Danno Ferrin]

Kevin, Stephen,
  Please review RT-36851.  There is one file in graphics in the application 
model affected by this change, and it is the most important change.  My 
rational is in the JIRA.

JIRA: https://javafx-jira.kenai.com/browse/RT-36851
WebRev: http://cr.openjdk.java.net/~shemnon/RT-36851/webrev.00/

Thanks,
--Danno

Review for RT-38968

[Danno Ferrin]

Chris, Kevin, 

Please review this patch.  More info in the JIRA

Webrev: http://cr.openjdk.java.net/~shemnon/RT-38968/webrev.00/
JIRA: https://javafx-jira.kenai.com/browse/RT-38968

Re: CFV: New OpenJFX Committer: Chris Bensen

[Danno Ferrin]

+1


On Oct 10, 2014, at 5:49 PM, Kevin Rushforth  wrote:

> I hereby nominate Chris Bensen to OpenJFX Committer.
> 
> Chris is a member of JavaFX team at Oracle working on the Java (FX) packager 
> tool.
> 
> A list of Chris' commits is available by the following link:
> 
> http://hg.openjdk.java.net/openjfx/8u-dev/rt/log?rev=cbensen
> 
> Four of the changesets in this list for which Chris was not listed as the 
> "author" were contributed by him, giving him a total of 8 changesets.
> 
> Additionally, the following is an aggregate changeset of significant work 
> contributed by both Danno and Chris (although the changeset comment doesn't 
> reflect that) :
> 
> http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8335da240a33
> 
> 
> Votes are due by October 24, 2014.
> 
> Only current OpenJFX Committers [1] are eligible to vote on this nomination. 
> Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2]. Nomination to a project 
> Committer is described in [3].
> 
> [1] http://openjdk.java.net/census#openjfx
> 
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> 
> [3] http://openjdk.java.net/projects#project-committer
> 
> Thanks,
> 
> -- Kevin
> 

Re: CFV: New OpenJFX Committer: Chris Bensen

[Danno Ferrin]

+1


On Oct 10, 2014, at 5:49 PM, Kevin Rushforth  wrote:

> I hereby nominate Chris Bensen to OpenJFX Committer.
> 
> Chris is a member of JavaFX team at Oracle working on the Java (FX) packager 
> tool.
> 
> A list of Chris' commits is available by the following link:
> 
> http://hg.openjdk.java.net/openjfx/8u-dev/rt/log?rev=cbensen
> 
> Four of the changesets in this list for which Chris was not listed as the 
> "author" were contributed by him, giving him a total of 8 changesets.
> 
> Additionally, the following is an aggregate changeset of significant work 
> contributed by both Danno and Chris (although the changeset comment doesn't 
> reflect that) :
> 
> http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8335da240a33
> 
> 
> Votes are due by October 24, 2014.
> 
> Only current OpenJFX Committers [1] are eligible to vote on this nomination. 
> Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2]. Nomination to a project 
> Committer is described in [3].
> 
> [1] http://openjdk.java.net/census#openjfx
> 
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> 
> [3] http://openjdk.java.net/projects#project-committer
> 
> Thanks,
> 
> -- Kevin
> 

Re: javapackager native windows bundle non empty app.classpath (package.cfg)

[Danno Ferrin]

This looks to be a bug.  Can you post what version of the jdk you are using?  
Also, can you post a JIRA for this at javafx-jira.kenai.com?


On Oct 6, 2014, at 2:13 PM, Stefan Kreutter  wrote:

> Hoping to address my question to the appropriate list...
> 
> Is it possible to use the javapackager (ant-tasks) to create a Windows exe 
> and having the app.classpath property of package.cfg populated? I use 
> something like this:
> 
>  outfile="${application.title}" verbose="true" width="600" height="400">
> mainClass="${javafx.main.class}"/>
>
>
>
>
> vendor="${application.vendor}" copyright="${application.copyright}">
>
>
> 
> 
> The directory target/dependency contains several jar files (which by the way 
> end up properly in the generated JNLP file) but only the jar file of the main 
> class is references in the package.cfg inside 
> native/bundles/${application.title}/app/package.cfg:
> 
> app.mainjar=app-1.0-SNAPSHOT.jar
> app.version=1.0
> app.id=org.example.demo.app
> app.preferences.id=org/example/demo/app
> app.mainclass= org/example/demo/app/DemoApp
> app.classpath=
> 
> In the source code of 
> java/com/sun/javafx/tools/packager/bundlers/WinAppBundler.java I found the 
> following comment:
> 
>> private void writePkgInfo(Map params, File 
>> pkgInfoFile) throws FileNotFoundException {
>>   [...]
>>  //This will be emtry string for correctly packaged JavaFX apps
>>  out.println("app.classpath=" + MAIN_JAR_CLASSPATH.fetchFrom(params));
>>   [...]
>> }
> 
> So it seems that having a classpath with  besides the main JAR is 
> not possible/wanted.
> 
> Thanks in advance,
> Stefan
> 

Review for RT-38725

[Danno Ferrin]

Kevin, Stephen, and anyone running Mac OSX 10.8 (Mountain Lion) with XCode 5.1.1

This patch should get the new launcher building on 10.7, 10.8, and 10.9 (and 
10.10 maybe when it is released).  However, we don't have anyone running 
Mountain Lion and/or XCode 5.1.1. The XCode issue is the more imprtaint one 
since JDK 9 appears to be moving to 5.1.1/clang on a 10.9 build machine, 
possibly with 10.8 SDK.  

Is there anyone on this list running either Mountain Lion or XCode 5.1.1 that 
could test this theory out?

It's verified on 10.7.5 with XCode 4.5 and 10.9.5 with XCode 6 with either the 
10.7 or 10.9 sdk.

WebRev:  http://cr.openjdk.java.net/~shemnon/RT-38725/webrev.00/
JIRA: https://javafx-jira.kenai.com/browse/RT-38725

Re: jfx:native - MSI installer change request

[Danno Ferrin]

I assume you are posting a bug to javafx-jira.kenai.com.  That is what will be 
needed to get it in the build.

On Oct 1, 2014, at 3:11 PM, Scott Lewis  wrote:

> Yes, a pass through would be just fine.  I don't think the order matters, if 
> there's a way I could just pass in the "-ext WixUIExtension" parameter, that 
> would suit our needs just fine :)
> 
> On 10/01/2014 04:10 PM, Danno Ferrin wrote:
>> Would a "pass through" of certian command line arguments work?
>> 
>> I'm not terribly familiar with WiX but does the order of the command line 
>> arguments (other than the relative order of the same command) matter?  i.e. 
>> if we insert a user supplied string at a single point would that get you as 
>> far as you need?
>> 
>> On Oct 1, 2014, at 3:04 PM, Scott Lewis  wrote:
>> 
>>> My apologies, I overlooked that this project has a JIRA tracker.  I'll file 
>>> this request there.
>>> 
>>> Scott
>>> 
>>> On 10/01/2014 03:59 PM, Scott Lewis wrote:
>>>> When I was using the jfx:native maven goal to create an installer for
>>>> Windows using MSI, most of it works fine.  However, I wanted to
>>>> customize the dialogs that are shown during the installation process.  I
>>>> can get the configuration files OK, but the problem is that in order for
>>>> it to work completely, the WixUIExtension needs to be included in the
>>>> command line (using an "-ext WixUIExtension" option).
>>>> 
>>>> Unfortunately, there is no way to add this when running the installer.
>>>> The code (WinMsiBundler.java) hardcodes the WixUtilExtension, but that
>>>> is all.
>>>> 
>>>> Ideally, it would be nice to be able to specify any number of arbitrary
>>>> extensions at the command line, perhaps via some kind of flag like
>>>> -Dextension=WixUIExtension, which then gets passed into the
>>>> WinMsiBundler to create more "-ext XYZExtension" options).  But even
>>>> just having the UI extension hardcoded inthere would get it to work.
>>>> 
>>>> I can probably just do the change locally and install a custom version
>>>> of the JFX stuff in my repository, but I think it would be a worthwhile
>>>> change to the repo overall.
>>>> 
>>>> Thanks!
>>>> 
>>>> Scott Lewis

Re: jfx:native - MSI installer change request

[Danno Ferrin]

Would a "pass through" of certian command line arguments work?

I'm not terribly familiar with WiX but does the order of the command line 
arguments (other than the relative order of the same command) matter?  i.e. if 
we insert a user supplied string at a single point would that get you as far as 
you need? 

On Oct 1, 2014, at 3:04 PM, Scott Lewis  wrote:

> My apologies, I overlooked that this project has a JIRA tracker.  I'll file 
> this request there.
> 
> Scott
> 
> On 10/01/2014 03:59 PM, Scott Lewis wrote:
>> When I was using the jfx:native maven goal to create an installer for
>> Windows using MSI, most of it works fine.  However, I wanted to
>> customize the dialogs that are shown during the installation process.  I
>> can get the configuration files OK, but the problem is that in order for
>> it to work completely, the WixUIExtension needs to be included in the
>> command line (using an "-ext WixUIExtension" option).
>> 
>> Unfortunately, there is no way to add this when running the installer.
>> The code (WinMsiBundler.java) hardcodes the WixUtilExtension, but that
>> is all.
>> 
>> Ideally, it would be nice to be able to specify any number of arbitrary
>> extensions at the command line, perhaps via some kind of flag like
>> -Dextension=WixUIExtension, which then gets passed into the
>> WinMsiBundler to create more "-ext XYZExtension" options).  But even
>> just having the UI extension hardcoded inthere would get it to work.
>> 
>> I can probably just do the change locally and install a custom version
>> of the JFX stuff in my repository, but I think it would be a worthwhile
>> change to the repo overall.
>> 
>> Thanks!
>> 
>> Scott Lewis

hg: openjfx/8u-dev/rt: RT-38312: Modify Packager to remove QT Kit platform when creating Mac App Store bundles

[danno . ferrin]

Changeset: ac413b6468e9
Author:shemnon
Date:  2014-09-18 23:07 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/ac413b6468e9

RT-38312: Modify Packager to remove QT Kit platform when creating Mac App Store 
bundles
Summary: Remove unneeded debugging code

! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacAppStoreBundler.java

hg: openjfx/8u-dev/rt: RT-38665: [packager] LauncherUserJVMOptions native headers incorrect

[danno . ferrin]

Changeset: 8501205d226c
Author:shemnon
Date:  2014-09-15 16:00 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8501205d226c

RT-38665: [packager] LauncherUserJVMOptions native headers incorrect
Summary: re-generate JNI headers and impls

! modules/fxpackager/src/main/native/library/common/Exports.cpp
! modules/fxpackager/src/main/native/library/common/Exports.h

Re: hg: openjfx/8u-dev/rt: support multiple file registrations on windows, and normalize the exe/msi names

[Danno Ferrin]

My bad, still in sandbox mode.

RT-38626: [Bundlers] content type is not set for Windows when specifying file 
associations
Summary: support multiple file registrations on windows, and normalize the 
exe/msi names

On Sep 11, 2014, at 11:05 AM, danno.fer...@shemnon.com wrote:

> Changeset: 554c4bdd3c5f
> Author:shemnon
> Date:  2014-09-11 11:04 -0600
> URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/554c4bdd3c5f
> 
> support multiple file registrations on windows, and normalize the exe/msi 
> names
> 
> ! 
> modules/fxpackager/src/main/java/com/oracle/tools/packager/windows/WinExeBundler.java
> ! 
> modules/fxpackager/src/main/java/com/oracle/tools/packager/windows/WinMsiBundler.java
> 

hg: openjfx/8u-dev/rt: support multiple file registrations on windows, and normalize the exe/msi names

[danno . ferrin]

Changeset: 554c4bdd3c5f
Author:shemnon
Date:  2014-09-11 11:04 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/554c4bdd3c5f

support multiple file registrations on windows, and normalize the exe/msi names

! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/windows/WinExeBundler.java
! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/windows/WinMsiBundler.java

hg: openjfx/8u-dev/rt: [test-only] need to check for Hand Crafted JDKs in build server tests.

[danno . ferrin]

Changeset: 6dea37f368c8
Author:shemnon
Date:  2014-09-11 08:02 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/6dea37f368c8

[test-only] need to check for Hand Crafted JDKs in build server tests.

! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacAppBundlerTest.java

hg: openjfx/8u-dev/rt: RT-37996: [packager] RPM Builder can't find rpmbuild in non-english locales

[danno . ferrin]

Changeset: ee31427caf20
Author:shemnon
Date:  2014-09-10 13:06 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/ee31427caf20

RT-37996: [packager] RPM Builder can't find rpmbuild in non-english locales
Summary: Just look for a version number, don't depend on language dependant 
cues.

! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/linux/LinuxRpmBundler.java

hg: openjfx/8u-dev/rt: RT-38567: Umbrella for Changes for JEP-208 - Java Packager Improvements

[danno . ferrin]

Changeset: 8335da240a33
Author:shemnon
Date:  2014-09-10 11:31 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8335da240a33

RT-38567: Umbrella for Changes for JEP-208 - Java Packager Improvements
Reviewed-By: kcr
Summary: Initial implementation for JEP-208, including work for RT-35388, 
RT-37766, RT-37767, RT-36118, RT-28833, RT-34187, RT-23918, RT-37769 which are 
all subtasks of the JEP.

! .hgignore
! build.gradle
! buildSrc/linux.gradle
! buildSrc/mac.gradle
! buildSrc/src/main/groovy/com/sun/javafx/gradle/CCTask.groovy
! buildSrc/win.gradle
! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/StandardBundlerParam.java
! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/linux/LinuxAppBundler.java
! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/linux/LinuxDebBundler.java
! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/linux/LinuxRpmBundler.java
! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacAppBundler.java
! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/windows/WinAppBundler.java
! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/windows/WinExeBundler.java
! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/windows/WinMsiBundler.java
! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/windows/WindowsBundlerParam.java
! modules/fxpackager/src/main/java/com/sun/javafx/tools/ant/DeployFXTask.java
+ modules/fxpackager/src/main/java/com/sun/javafx/tools/ant/FileAssociation.java
! modules/fxpackager/src/main/java/com/sun/javafx/tools/ant/Info.java
+ 
modules/fxpackager/src/main/java/com/sun/javafx/tools/ant/SecondaryLauncher.java
! 
modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/DeployParams.java
! 
modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/BundleParams.java
+ 
modules/fxpackager/src/main/java/jdk/packager/services/UserJvmOptionsService.java
+ 
modules/fxpackager/src/main/java/jdk/packager/services/userjvmoptions/LauncherUserJvmOptions.java
+ 
modules/fxpackager/src/main/java/jdk/packager/services/userjvmoptions/PreferencesUserJvmOptions.java
! modules/fxpackager/src/main/native/javapackager/win/javapackager.cpp
- modules/fxpackager/src/main/native/launcher/linux/DeployPlatform.h
- modules/fxpackager/src/main/native/launcher/linux/launcher.c
+ modules/fxpackager/src/main/native/launcher/linux/launcher.cpp
+ 
modules/fxpackager/src/main/native/launcher/linux/test/CppApplication_1/.dep.inc
+ 
modules/fxpackager/src/main/native/launcher/linux/test/CppApplication_1/Makefile
+ 
modules/fxpackager/src/main/native/launcher/linux/test/CppApplication_1/nbproject/Makefile-Debug.mk
+ 
modules/fxpackager/src/main/native/launcher/linux/test/CppApplication_1/nbproject/Makefile-Release.mk
+ 
modules/fxpackager/src/main/native/launcher/linux/test/CppApplication_1/nbproject/Makefile-impl.mk
+ 
modules/fxpackager/src/main/native/launcher/linux/test/CppApplication_1/nbproject/Makefile-variables.mk
+ 
modules/fxpackager/src/main/native/launcher/linux/test/CppApplication_1/nbproject/Package-Debug.bash
+ 
modules/fxpackager/src/main/native/launcher/linux/test/CppApplication_1/nbproject/Package-Release.bash
+ 
modules/fxpackager/src/main/native/launcher/linux/test/CppApplication_1/nbproject/configurations.xml
+ 
modules/fxpackager/src/main/native/launcher/linux/test/CppApplication_1/nbproject/project.xml
- modules/fxpackager/src/main/native/launcher/linux/xmlparser.c
- modules/fxpackager/src/main/native/launcher/linux/xmlparser.h
! modules/fxpackager/src/main/native/launcher/mac/main.m
+ 
modules/fxpackager/src/main/native/launcher/mac/test/testlauncher/testlauncher.xcodeproj/project.pbxproj
+ 
modules/fxpackager/src/main/native/launcher/mac/test/testlauncher/testlauncher.xcodeproj/project.xcworkspace/contents.xcworkspacedata
+ 
modules/fxpackager/src/main/native/launcher/mac/test/testlauncher/testlauncher/AppDelegate.h
+ 
modules/fxpackager/src/main/native/launcher/mac/test/testlauncher/testlauncher/AppDelegate.m
+ 
modules/fxpackager/src/main/native/launcher/mac/test/testlauncher/testlauncher/Base.lproj/MainMenu.xib
+ 
modules/fxpackager/src/main/native/launcher/mac/test/testlauncher/testlauncher/Images.xcassets/AppIcon.appiconset/Contents.json
+ 
modules/fxpackager/src/main/native/launcher/mac/test/testlauncher/testlauncher/en.lproj/Credits.rtf
+ 
modules/fxpackager/src/main/native/launcher/mac/test/testlauncher/testlauncher/en.lproj/InfoPlist.strings
+ 
modules/fxpackager/src/main/native/launcher/mac/test/testlauncher/testlauncher/testlauncher-Info.plist
+ 
modules/fxpackager/src/main/native/launcher/mac/test/testlauncher/testlauncher/testlauncher-Prefix.pch
+ 
modules/fxpackager/src/main/native/launcher/mac/test/testlauncher/testlauncherTests/en.lproj/InfoPlist.strings
+ 
modules/fxpackager/src/main/native/launcher/mac/test/testlauncher/testlauncherTests/testlauncherTests-Info.plist
+ 
modules/fxpackager/src/main/native/launcher/mac/test/testl

hg: openjfx/8u-dev/rt: [test-only] RT-38575: Java FX 8u40 build got stuck because hdiutil is hanging when it receives a message "will sleep received"

[danno . ferrin]

Changeset: bace5fdce0fe
Author:shemnon
Date:  2014-09-09 18:46 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/bace5fdce0fe

[test-only] RT-38575: Java FX 8u40 build got stuck because hdiutil is hanging 
when it receives a message "will sleep received"
Summary: Only run DMG tests when explicitly requested
Reviewed-By: kcr

! build.gradle
! gradle.properties.template
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacDmgBundlerTest.java

Re: IOS support?

[Danno Ferrin]

There's a JavaOne session for that:

Java on iOS? Yes, You Can! [CON3698]
• Henric Müller - CEO, Trillian Mobile AB
• Niklas Therning - Head Geek, RoboVM / Trillian Mobile AB
Tuesday, Sep 30, 11:00 AM - 12:00 PM - Hilton - Yosemite B/C

https://oracleus.activeevents.com/2014/connect/sessionDetail.ww?SESSION_ID=3698

On Sep 9, 2014, at 12:59 PM, Tony Anecito  wrote:

> Hi All,
> Does someone plan to support Java on IOS? Be great with the inroads openjfx 
> has made with Apple to get java running on IOS so developers do not have to 
> use ObjectiveC.
> 
> Perhaps someone has a swing/jfx jvm running on IOS or something close to 
> supporting both?
> 
> Thanks!
> -Tony

[8u40] Review of JEP-208 / RT-38576 - Java Packager Improvements

[Danno Ferrin]

Kevin, Stephen:
Please review.  There is a new bug ID for previous reviews, discuss it on the 
javafx-jira site instead of on the JEP bug.   Also a windows build tpyo was 
fixed, other than that the webrev is teh same.  Child bugs linked in the 
umbrella bug.

JIRA: https://javafx-jira.kenai.com/browse/RT-38567
WebRev: http://cr.openjdk.java.net/~shemnon/RT-38567/webrev.00/

Review for JDK-8043060 - First Impl for JEP-208 Packager Imrpovments

[Danno Ferrin]

Kevin, Steve,

Please review this first implementation of the features for JEP-208, tracked on 
bugs.openjdk.java.net as JDK-8043060.  There are some changes to the build 
support classes to support compiling Mac ".mm" files as well as some platform 
specific flags added tot he platform .gradles in buildSrc, so a +1 (or 
directions for improvement) from the build masters would be appreciated.

WebRev: http://cr.openjdk.java.net/~shemnon/JDK-8043060/webrev.00/
JIRA: https://bugs.openjdk.java.net/browse/JDK-8043060

This patch also encompasses the following OpenJFX JIRAs (all linked in the 
jep), although the discussion for this webrev should be in the JDK-8043060 bug.

RT-23918 - Native bundles: add support to create file association
RT-28833 - Single source native launcher
RT-35388 - JavaFX Packager's launcher only works with JDK not JRE
RT-36118 - Support multiple entry points in native installer
RT-37766 - [packager] Respect command line arguments in self contained 
applications
RT-37767 - [packager] Provide friendly APIs to access User JVM 
Preferences
RT-37769 - [packager] Simple DMG Generation

hg: openjfx/8u-dev/rt: [test-only] change to simple DMG

[danno . ferrin]

Changeset: 613a8ae3a0f4
Author:shemnon
Date:  2014-09-03 19:59 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/613a8ae3a0f4

[test-only] change to simple DMG
When running tests, only do a full DMG if the build is configured to retain the 
intermediate packaging artifacts

! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacDmgBundlerTest.java

Re: Javapackager not calling MyApp-post-image.sh on MacOSX

[Danno Ferrin]

Excellent point.  I'll move the script to before the codesign.

I've also got some bugs requesting an easy flag to turn off auto-codesign.  
I'll do that as part of the 8u40 work.

In the mean time, you can disable codesign with a bundler argument in ant by 
adding this to the fx:deploy element

 

(for cli it is -Bmac.signing-key-user-name=Nonexistent User)

Then in your post image script you can hand wire the signing.

On Sep 3, 2014, at 3:43 PM, Jeff Martin  wrote:

> I just tested with DMG and my script does get called. However, it seems like 
> I can’t use it to add and remove JDK files without invalidating the codesign 
> work. Is it possible for javapackager to build the image, call the post-image 
> script, then codesign?
> 
> jeff
> 
> 
> On Sep 3, 2014, at 4:33 PM, Jeff Martin  wrote:
> 
>> Done: RT-38521 - Javapackager not calling post-image script on MacOSX for 
>> PKG and IMAGE
>> 
>> jeff
>> 
>> 
>> On Sep 3, 2014, at 4:15 PM, Danno Ferrin  wrote:
>> 
>>> A quick code inspection shows that the post image script is only called for 
>>> DMG packaging.  Looks to be a PKG oversight.  Could you post a bug to 
>>> javafx-jira.kenai.com?
>>> 
>>> On Sep 3, 2014, at 2:31 PM, Jeff Martin  wrote:
>>> 
>>>> Actually, for the moment I’m just generating “image”, though I tried pkg 
>>>> and it also didn’t call the post-image script.
>>>> 
>>>> I love all the customization tips when verbose is turned on. I was hoping 
>>>> it would say, “No post-image script found at 
>>>> package/macosx/SnapCode-post-image.sh - add one here for customization”.
>>>> 
>>>> jeff
>>>> 
>>>> 
>>>> On Sep 3, 2014, at 2:46 PM, Danno Ferrin  wrote:
>>>> 
>>>>> What mac package format?  DMG or PKG?
>>>>> 
>>>>> 
>>>>> On Sep 3, 2014, at 12:38 PM, Jeff Martin  wrote:
>>>>> 
>>>>>> I’m glad to see that javafxpackager is now javapackager. So my question 
>>>>>> should be - what is the proper forum to post a javapackger question, or 
>>>>>> who at Oracle could create a new dedicated forum for it?
>>>>>> 
>>>>>> In the meantime, does anyone have a suggestion to diagnose why my custom 
>>>>>> package/macosx/MyApp-post-image.sh isn’t getting called? Javapackager is 
>>>>>> picking up my custom icons fine, and the windows post-image.wsf is 
>>>>>> getting picked up fine. Just not getting called on MacOSX.
>>>>>> 
>>>>>> jeff

Re: Javapackager not calling MyApp-post-image.sh on MacOSX

[Danno Ferrin]

A quick code inspection shows that the post image script is only called for DMG 
packaging.  Looks to be a PKG oversight.  Could you post a bug to 
javafx-jira.kenai.com?

On Sep 3, 2014, at 2:31 PM, Jeff Martin  wrote:

> Actually, for the moment I’m just generating “image”, though I tried pkg and 
> it also didn’t call the post-image script.
> 
> I love all the customization tips when verbose is turned on. I was hoping it 
> would say, “No post-image script found at 
> package/macosx/SnapCode-post-image.sh - add one here for customization”.
> 
> jeff
> 
> 
> On Sep 3, 2014, at 2:46 PM, Danno Ferrin  wrote:
> 
>> What mac package format?  DMG or PKG?
>> 
>> 
>> On Sep 3, 2014, at 12:38 PM, Jeff Martin  wrote:
>> 
>>> I’m glad to see that javafxpackager is now javapackager. So my question 
>>> should be - what is the proper forum to post a javapackger question, or who 
>>> at Oracle could create a new dedicated forum for it?
>>> 
>>> In the meantime, does anyone have a suggestion to diagnose why my custom 
>>> package/macosx/MyApp-post-image.sh isn’t getting called? Javapackager is 
>>> picking up my custom icons fine, and the windows post-image.wsf is getting 
>>> picked up fine. Just not getting called on MacOSX.
>>> 
>>> jeff
>> 
> 

Re: Javapackager not calling MyApp-post-image.sh on MacOSX

[Danno Ferrin]

What mac package format?  DMG or PKG?


On Sep 3, 2014, at 12:38 PM, Jeff Martin  wrote:

> I’m glad to see that javafxpackager is now javapackager. So my question 
> should be - what is the proper forum to post a javapackger question, or who 
> at Oracle could create a new dedicated forum for it?
> 
> In the meantime, does anyone have a suggestion to diagnose why my custom 
> package/macosx/MyApp-post-image.sh isn’t getting called? Javapackager is 
> picking up my custom icons fine, and the windows post-image.wsf is getting 
> picked up fine. Just not getting called on MacOSX.
> 
> jeff

8u40 API Review: RT-37767 Provide friendly APIs to access User JVM Preferences

[Danno Ferrin]

webrev: http://cr.openjdk.java.net/~shemnon/RT-37767/webrev.0/
Jira: https://javafx-jira.kenai.com/browse/RT-37767

This is the proposed API to allow the friendly access tot eh User JVM Options.

Here are some snippets from demo code on my machine showing how they may 
interact:

// get the helper instance
UserJvmOptions ujo = UserJvmOptions.getUserJVMDefaults();
Map userOptions = ujo.getUserJVMOptions();

// print out all the options currently set
for (Map.Entry  entry : userOptions.entrySet()) {
System.out.println("key:" + entry.getKey() + " value:" + 
entry.getValue());
}

// if we haven't marked the first run, do so now
if (!userOptions.containsKey("-DfirstRunMs")) {
userOptions.put("-DfirstRunMs", 
Long.toString(System.currentTimeMillis()));
}

// add the last run
userOptions.put("-DlastRunMs", 
Long.toString(System.currentTimeMillis()));

// save the changes
ujo.setUserJVMOptions(userOptions);



// create a table row with Key, Current Value, and Default Value
DefaultTableModel model = new DefaultTableModel();
model.addColumn("Key");
model.addColumn("Effective");
model.addColumn("Default");

Map defaults = ujo.getUserJVMOptionDefaults();
for (Map.Entry  entry : userOptions.entrySet()) {
// get the default, it may be null
String def = defaults.get(entry.getKey());

model.addRow(new Object[] {entry.getKey(), entry.getValue(), def == 
null ? "" : def});
}

hg: openjfx/8u-dev/rt: RT-38442: [packager] Java FX Packaging options can cause Windows Packager to fail.

[danno . ferrin]

Changeset: e4cfda6bac5a
Author:shemnon
Date:  2014-08-26 14:28 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e4cfda6bac5a

RT-38442: [packager] Java FX Packaging options can cause Windows Packager to 
fail.
Summary: regexp needs double backslash, so that means quadruple in the source 
code.

! build.gradle
! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/windows/WinAppBundler.java
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/windows/WinAppBundlerTest.java
! 
modules/graphics/src/main/java/com/sun/javafx/css/converters/SizeConverter.java

Re: How to set CFBundleVersion?

[Danno Ferrin]

From CLI use the -v flag

for ant, verbose is an element on the fx:deploy task

For the new 8u20 API, the bundler argument is "verbose" and the value is "true"

On Aug 25, 2014, at 11:10 AM, Tony Anecito  wrote:

> How do I run verbose with the bundler?
> 
> Thanks!
> -Tony
> 
> 
> On Monday, August 25, 2014 10:53 AM, Danno Ferrin  
> wrote:
> 
> 
> Not at the moment.  This is a task I hope to get to in 8u40.
> 
> It needs to be in the classpath of the ant-javafx.jar in a specific place, 
> which I believe is package/macosx/Info.plist.  IIRC the verbose output tells 
> you the name.
> 
> 
> On Aug 25, 2014, at 9:58 AM, Tony Anecito  wrote:
> 
>> Yep I meant CFBundleVersion.
>> 
>> 
>> Does the bundler allow me to specify the location of a info.plst to use? 
>> That way I can get the one the bundler has created, modify it to include the 
>> new info.plist with the CFBundleVersion set to what I need and then run the 
>> bundler to use that info.plist.
>> 
>> Thanks,
>> -Tony
>> 
>> 
>> 
>> 
>> On Monday, August 25, 2014 8:47 AM, Danno Ferrin  
>> wrote:
>> 
>> 
>> Do you mean CFBundleVersion?  (no r).
>> 
>> This is a bug for 8u40:  https://javafx-jira.kenai.com/browse/RT-37833
>> 
>> In the mean time I took the info.plist, used the drop-in-resource facility, 
>> and provided my own template. Then I hand incremented the CFBundle.
>> 
>> If you run with verbose set the Info.PList the bundler provides internally 
>> will be saved to a temp directory, and you can just modify it from there.
>> 
>> I can confirm from personal use the workaround I just described works.
>> 
>> On Aug 25, 2014, at 12:23 AM, Tony Anecito  wrote:
>> 
>> > Hi Danno,
>> > 
>> > How does one set or increment the CFBundlerVersion value? I tried the 
>> > bundleArgument but that did not work. 
>> > When submitting an updated app to Apple itunes this has to be greater than 
>> > the last version which looks lik by default it is 100.
>> > 
>> > Thanks!
>> > -Tony
>> 
>> 
> 
> 
> 

Re: How to set CFBundleVersion?

[Danno Ferrin]

Not at the moment.  This is a task I hope to get to in 8u40.

It needs to be in the classpath of the ant-javafx.jar in a specific place, 
which I believe is package/macosx/Info.plist.  IIRC the verbose output tells 
you the name.


On Aug 25, 2014, at 9:58 AM, Tony Anecito  wrote:

> Yep I meant CFBundleVersion.
> 
> 
> Does the bundler allow me to specify the location of a info.plst to use? That 
> way I can get the one the bundler has created, modify it to include the new 
> info.plist with the CFBundleVersion set to what I need and then run the 
> bundler to use that info.plist.
> 
> Thanks,
> -Tony
> 
> 
> 
> 
> On Monday, August 25, 2014 8:47 AM, Danno Ferrin  
> wrote:
> 
> 
> Do you mean CFBundleVersion?  (no r).
> 
> This is a bug for 8u40:  https://javafx-jira.kenai.com/browse/RT-37833
> 
> In the mean time I took the info.plist, used the drop-in-resource facility, 
> and provided my own template. Then I hand incremented the CFBundle.
> 
> If you run with verbose set the Info.PList the bundler provides internally 
> will be saved to a temp directory, and you can just modify it from there.
> 
> I can confirm from personal use the workaround I just described works.
> 
> On Aug 25, 2014, at 12:23 AM, Tony Anecito  wrote:
> 
> > Hi Danno,
> > 
> > How does one set or increment the CFBundlerVersion value? I tried the 
> > bundleArgument but that did not work. 
> > When submitting an updated app to Apple itunes this has to be greater than 
> > the last version which looks lik by default it is 100.
> > 
> > Thanks!
> > -Tony
> 
> 

Re: How to set CFBundleVersion?

[Danno Ferrin]

Do you mean CFBundleVersion?  (no r).

This is a bug for 8u40:  https://javafx-jira.kenai.com/browse/RT-37833

In the mean time I took the info.plist, used the drop-in-resource facility, and 
provided my own template. Then I hand incremented the CFBundle.

If you run with verbose set the Info.PList the bundler provides internally will 
be saved to a temp directory, and you can just modify it from there.

I can confirm from personal use the workaround I just described works.

On Aug 25, 2014, at 12:23 AM, Tony Anecito  wrote:

> Hi Danno,
> 
> How does one set or increment the CFBundlerVersion value? I tried the 
> bundleArgument but that did not work. 
> When submitting an updated app to Apple itunes this has to be greater than 
> the last version which looks lik by default it is 100.
> 
> Thanks!
> -Tony

hg: openjfx/8u-dev/rt: [test only] RT-37439: Install packaged JDK and JRE on Mac Build Servers

[danno . ferrin]

Changeset: eeb8252d3fed
Author:shemnon
Date:  2014-08-22 10:03 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/eeb8252d3fed

[test only] RT-37439: Install packaged JDK and JRE on Mac Build Servers
Summary: three more missed values

! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacAppBundlerTest.java

hg: openjfx/8u-dev/rt: [test only] RT-37439: Install packaged JDK and JRE on Mac Build Servers

[danno . ferrin]

Changeset: 92969d8fa8b7
Author:shemnon
Date:  2014-08-22 08:12 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/92969d8fa8b7

[test only] RT-37439: Install packaged JDK and JRE on Mac Build Servers
Summary: a few more missed values

! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacAppBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacDmgBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacPkgBundlerTest.java

hg: openjfx/8u-dev/rt: RT-37439: Install packaged JDK and JRE on Mac Build Servers

[danno . ferrin]

Changeset: fb4402463363
Author:shemnon
Date:  2014-08-21 19:53 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/fb4402463363

RT-37439: Install packaged JDK and JRE on Mac Build Servers
Summary: Fix typing errors.

! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacAppBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacAppStoreBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacDaemonBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacDmgBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacPkgBundlerTest.java

hg: openjfx/8u-dev/rt: RT-37439: Install packaged JDK and JRE on Mac Build Servers

[danno . ferrin]

Changeset: 946598c40f55
Author:shemnon
Date:  2014-08-21 12:41 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/946598c40f55

RT-37439: Install packaged JDK and JRE on Mac Build Servers
Summary: update tests to respect the new environmental parameters when present.

! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacAppStoreBundler.java
! 
modules/fxpackager/src/main/resources/com/oracle/tools/packager/mac/MacAppStoreBundler.properties
! modules/fxpackager/src/test/java/com/oracle/tools/packager/CLITest.java
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacAppBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacAppStoreBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacDaemonBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacDmgBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacPkgBundlerTest.java

hg: openjfx/8u-dev/rt: 2 new changesets

[danno . ferrin]

Changeset: a4ba2aff078e
Author:shemnon
Date:  2014-08-20 10:49 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a4ba2aff078e

RT-38129 - mac.dmg.simple hangs
Summary: fix logic error

! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacDmgBundler.java

Changeset: e28ed8b67772
Author:shemnon
Date:  2014-08-20 10:52 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e28ed8b67772

RT-38312: Modify Packager to remove QT Kit platform when creating Mac App Store 
bundles
and RT-37732:[packager] Default argument lambdas should be well behaved
Summary: Sometimes the "default" values are truly unacceptable.  In those cases 
a ConfigException wrapped in a RuntimeException is acceptable way to 
communicate that.  In this case a runtime configured to a non-mac layout is not 
acceptable, and some default unconfigured environments will see that.

! modules/fxpackager/src/test/java/com/oracle/tools/packager/BundlersTest.java

hg: openjfx/8u-dev/rt: RT-38312: Modify Packager to remove QT Kit platform when creating Mac App Store bundles

[danno . ferrin]

Changeset: 7e5faca81800
Author:shemnon
Date:  2014-08-14 15:27 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/7e5faca81800

RT-38312: Modify Packager to remove QT Kit platform when creating Mac App Store 
bundles
Summary: The runtime check caused problems when run on windows and linux, make 
sure that doesn't happen.

! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacAppBundler.java

hg: openjfx/8u-dev/rt: RT-38312: Modify Packager to remove QT Kit platform when creating Mac App Store bundles

[danno . ferrin]

Changeset: f7cf21c9e487
Author:shemnon
Date:  2014-08-14 10:48 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/f7cf21c9e487

RT-38312: Modify Packager to remove QT Kit platform when creating Mac App Store 
bundles
Summary: update the part of the MacAppBundler where the JDK runtime rules are 
calculated, so we pay attention to what libraries are present and exclude based 
on what is there.
Also, update some outdated web links in comments relating to JDK stripping

! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/linux/LinuxAppBundler.java
! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacAppBundler.java
! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacAppStoreBundler.java
! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/windows/WindowsBundlerParam.java
! 
modules/fxpackager/src/main/resources/com/oracle/tools/packager/mac/MacAppBundler.properties
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacAppBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacAppStoreBundlerTest.java

hg: openjfx/8u-dev/rt: RT-38129 - mac.dmg.simple hangs

[danno . ferrin]

Changeset: 4f273765662a
Author:shemnon
Date:  2014-08-13 09:01 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/4f273765662a

RT-38129 - mac.dmg.simple hangs
Summary: remove all fancy linkage.  DMG is now very simple: .app only.

! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacDmgBundler.java

Re: Bundle native libraries for Mac for JNA & JNI...

[Danno Ferrin]

I think that is right.  We set java.library.path in the launcher to be 
/Contents/Java/ prior to launch.  So I would include the libraries in 
the same way the jars and other assets are listed.

On Aug 10, 2014, at 9:20 PM, Tony Anecito  wrote:

> Ok. I think the native libraries should be placed under MacOS folder in the 
> app file say under a folder structure I define so my code can find it using a 
> jna native call.
>  
> Iam still researhing it some more tonight.
>  
> Thanks,
> -Tony 
> 
> 
> On Sunday, August 10, 2014 9:09 AM, Tony Anecito  wrote:
> 
> 
> 
> Hi All,
> 
> I need to bundle Mac native libraries so that JNA and JNI can find them. I 
> can not bundle inside a jar since JNA will not find them. But I want the 
> native libraries to be found inside the .app file say in a lib folder.
> Anyone know how to do that using javafx deploy ant scripts? Is there some 
> special directory I have to setup like I do for icns?
> 
> Thanks!
> -Tony

Re: hg: openjfx/8u-dev/rt: RT-37832: [packager] Mac App Store Bundler fails to strip jfxmedia.dylib and strips Info.plist

[Danno Ferrin]

FYI b23 just went live on the EA site: 

https://jdk8.java.net/download.html



> 
> 
> On Tuesday, July 8, 2014 3:18 PM, Kevin Rushforth 
>  wrote:
> 
> 
> As soon as EA builds of 8u40 start up (nor sure exactly when but likely in 1 
> or 2 weeks) you can get the fix from 8u40-b01. If you don't mind using JDK 9, 
> the fix will be in 9-b22 which should be out on Friday or Monday.
> 
> Not sure when / if 8u20-b23 will be available (it's the GA candidate build 
> and those are often not posted on java.net).
> 
> -- Kevin
> 
> 
> Tony Anecito wrote:
>> Ok. Something odd happened I never seen before and acts like issue might be 
>> with Info.pList in the pkg file. The app file works just fine.
>> 
>> -Tony
>> 
>> 
>> On Tuesday, July 8, 2014 2:59 PM, Danno Ferrin  
>> wrote:
>> 
>> 
>> The Info.plist in the plugins dir.  i.e. 
>> /Contents/PlugIns//Contents/Info.plist - we should be 
>> preserving this as I believe apple checks the meta-data for it.  I still 
>> haven’t been able to sign it in a way the ApplicationLoader won’t complain, 
>> but it is just a warning at the moment.
>> 
>> It’s been broken since b18, the second week of June.
>> 
>> As for when b23 will appear, that’s always been above my pay grade.  The fix 
>> is in the 8u40 line at the moment, and to get stuff into 8u20 involves 
>> committee approval now.  Looks good, but I don’t sit in or listen into those 
>> meetings.  The HG repo to keep an eye on is 
>> http://hg.openjdk.java.net/openjfx/8u20/rt/, and I missed the b22 build but 
>> the repo isn’t reflecting that yet.
>> 
>> On Jul 8, 2014, at 2:02 PM, Tony Anecito  wrote:
>> 
>> > Thanks Kevin. I know why the media libraries need to not be present but 
>> > not what the stripped Info.plist means.
>> > 
>> > So when might b23 appear?
>> > 
>> > Thanks,
>> > -Tony
>> > 
>> > 
>> > 
>> > On Tuesday, July 8, 2014 1:53 PM, Kevin Rushforth 
>> >  wrote:
>> > 
>> > 
>> > 
>> > Danno will answer the first question (it is related to needing to omit 
>> > the media libraries). As to when it will appear, if it is approved for 
>> > inclusion into 8u20 it will be in b23.
>> > 
>> > -- Kevin
>> > 
>> > 
>> > 
>> > Tony Anecito wrote:
>> >> Hi Danno,
>> >> 
>> >> What do you mean by strips Info.plist? I am having a strange problem 
>> >> using b20 and wondering if it is related to what you meant by stripped 
>> >> Info.plist.
>> >> Also, what build will this be fixed in?
>> >> 
>> >> Thanks,
>> >> -Tony
>> >> 
>> >> 
>> >> 
>> >> On Monday, July 7, 2014 2:46 PM, "danno.fer...@shemnon.com" 
>> >>  wrote:
>> >>  
>> >> 
>> >> 
>> >> Changeset: 7398ae52202d
>> >> Author:shemnon
>> >> Date:  2014-07-07 10:51 -0600
>> >> URL:  http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/7398ae52202d
>> >> 
>> >> RT-37832: [packager] Mac App Store Bundler fails to strip jfxmedia.dylib 
>> >> and strips Info.plist
>> >> Summary: unit test for file verifications
>> >> 
>> >> ! 
>> >> modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacAppStoreBundlerTest.java
>> >>  
>> 
>> 
> 
> 

hg: openjfx/8u-dev/rt: RT-37769: Simple DMG Generation

[danno . ferrin]

Changeset: 22be6271b7d3
Author:shemnon
Date:  2014-07-10 12:32 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/22be6271b7d3

RT-37769: Simple DMG Generation
Summary: Add a bundler argument, and skip the applescript step if it is set.  
If it is simple and system wide add a non-exciting link to /Applications in the 
DMG.

! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacBaseInstallerBundler.java
! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacDmgBundler.java
! 
modules/fxpackager/src/main/resources/com/oracle/tools/packager/mac/DMGsetup.scpt
! 
modules/fxpackager/src/main/resources/com/oracle/tools/packager/mac/MacDmgBundler.properties
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacDmgBundlerTest.java

Re: OT: Netbeans ported to JFX?

[Danno Ferrin]

On Jul 9, 2014, at 8:14 AM, Jeff Martin  wrote:

> We need something like a "JavaFX Playground"

Something like this?  https://www.youtube.com/watch?v=g2DJb58at10

Looks like Carl will also be presenting this at JavaOne this year.

—Danno

hg: openjfx/8u-dev/rt: 2 new changesets

[danno . ferrin]

Changeset: 815b29fce85f
Author:shemnon
Date:  2014-07-09 14:41 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/815b29fce85f

RT-37833: [packager] Allow for easier configuration of CFBundleVersion for 
Mac/Mac App Store
Summary: Add a mac.CFBundlerVersion bundler argument.  Defaults to appVersion 
if appVersion is appropriate, 100 otherwise.  Validated as well.

! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacAppBundler.java
! 
modules/fxpackager/src/main/resources/com/oracle/tools/packager/mac/Info.plist.template
! 
modules/fxpackager/src/main/resources/com/oracle/tools/packager/mac/MacAppBundler.properties
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacAppBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacAppStoreBundlerTest.java

Changeset: d132c15d52f9
Author:shemnon
Date:  2014-07-09 14:42 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/d132c15d52f9

[test-only] - remove stray bundle param, remove dead allocations.

! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/windows/WinServiceBundlerTest.java

Re: hg: openjfx/8u-dev/rt: RT-37832: [packager] Mac App Store Bundler fails to strip jfxmedia.dylib and strips Info.plist

[Danno Ferrin]

What sort of something wrong?  can you describe the failure behavior? 

Does the app completely bomb out?  The file dialog will cause the app to bomb 
out right now, even with the correct entitlements: 
https://javafx-jira.kenai.com/browse/RT-37261 and it won’t be fixed until 8u40.

If it is some other failure, please describe it.  It does weird things wight he 
container and setting user.home as well.

To specify the entitlements either use the bundler argument 
'mac.app-store-entitlements’ and enter the file path (build time) or add a 
drop-in resource named .entitlements much like you would an icon.  

This is for the top level, all other files are signed with an “inherit” sandbox 
that I have anecdotal evidence is better than identical entitlements.  This 
inherit entitlement can be overridden with an -inherit.entitlements 
drop-in resource.


On Jul 8, 2014, at 3:45 PM, Tony Anecito  wrote:

> Thanks Kevin,
> 
> Danno - Something is wrong specifically with the pkg file for Apple iTunes. 
> The app, dmg and regular pkg all work fine. It is like there is a permissions 
> issue and my app for that pkg can not read or write or both to the disk. It 
> is like my entitlements file is not being read and used for the that pkg 
> file. I do specify my entitlements file name in my ant script. How does the 
> packager know what the entitlement file name and location is?
> 
> Thanks,
> -Tony
> 
> 
> On Tuesday, July 8, 2014 3:18 PM, Kevin Rushforth 
>  wrote:
> 
> 
> As soon as EA builds of 8u40 start up (nor sure exactly when but likely in 1 
> or 2 weeks) you can get the fix from 8u40-b01. If you don't mind using JDK 9, 
> the fix will be in 9-b22 which should be out on Friday or Monday.
> 
> Not sure when / if 8u20-b23 will be available (it's the GA candidate build 
> and those are often not posted on java.net).
> 
> -- Kevin
> 
> 
> Tony Anecito wrote:
>> Ok. Something odd happened I never seen before and acts like issue might be 
>> with Info.pList in the pkg file. The app file works just fine.
>> 
>> -Tony
>> 
>> 
>> On Tuesday, July 8, 2014 2:59 PM, Danno Ferrin  
>> wrote:
>> 
>> 
>> The Info.plist in the plugins dir.  i.e. 
>> /Contents/PlugIns//Contents/Info.plist - we should be 
>> preserving this as I believe apple checks the meta-data for it.  I still 
>> haven’t been able to sign it in a way the ApplicationLoader won’t complain, 
>> but it is just a warning at the moment.
>> 
>> It’s been broken since b18, the second week of June.
>> 
>> As for when b23 will appear, that’s always been above my pay grade.  The fix 
>> is in the 8u40 line at the moment, and to get stuff into 8u20 involves 
>> committee approval now.  Looks good, but I don’t sit in or listen into those 
>> meetings.  The HG repo to keep an eye on is 
>> http://hg.openjdk.java.net/openjfx/8u20/rt/, and I missed the b22 build but 
>> the repo isn’t reflecting that yet.
>> 
>> On Jul 8, 2014, at 2:02 PM, Tony Anecito  wrote:
>> 
>> > Thanks Kevin. I know why the media libraries need to not be present but 
>> > not what the stripped Info.plist means.
>> > 
>> > So when might b23 appear?
>> > 
>> > Thanks,
>> > -Tony
>> > 
>> > 
>> > 
>> > On Tuesday, July 8, 2014 1:53 PM, Kevin Rushforth 
>> >  wrote:
>> > 
>> > 
>> > 
>> > Danno will answer the first question (it is related to needing to omit 
>> > the media libraries). As to when it will appear, if it is approved for 
>> > inclusion into 8u20 it will be in b23.
>> > 
>> > -- Kevin
>> > 
>> > 
>> > 
>> > Tony Anecito wrote:
>> >> Hi Danno,
>> >> 
>> >> What do you mean by strips Info.plist? I am having a strange problem 
>> >> using b20 and wondering if it is related to what you meant by stripped 
>> >> Info.plist.
>> >> Also, what build will this be fixed in?
>> >> 
>> >> Thanks,
>> >> -Tony
>> >> 
>> >> 
>> >> 
>> >> On Monday, July 7, 2014 2:46 PM, "danno.fer...@shemnon.com" 
>> >>  wrote:
>> >>  
>> >> 
>> >> 
>> >> Changeset: 7398ae52202d
>> >> Author:shemnon
>> >> Date:  2014-07-07 10:51 -0600
>> >> URL:  http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/7398ae52202d
>> >> 
>> >> RT-37832: [packager] Mac App Store Bundler fails to strip jfxmedia.dylib 
>> >> and strips Info.plist
>> >> Summary: unit test for file verifications
>> >> 
>> >> ! 
>> >> modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacAppStoreBundlerTest.java
>> >>  
>> 
>> 
> 
> 

Re: hg: openjfx/8u-dev/rt: RT-37832: [packager] Mac App Store Bundler fails to strip jfxmedia.dylib and strips Info.plist

[Danno Ferrin]

The Info.plist in the plugins dir.  i.e. 
/Contents/PlugIns//Contents/Info.plist - we should be preserving 
this as I believe apple checks the meta-data for it.  I still haven’t been able 
to sign it in a way the ApplicationLoader won’t complain, but it is just a 
warning at the moment.

It’s been broken since b18, the second week of June.

As for when b23 will appear, that’s always been above my pay grade.  The fix is 
in the 8u40 line at the moment, and to get stuff into 8u20 involves committee 
approval now.  Looks good, but I don’t sit in or listen into those meetings.  
The HG repo to keep an eye on is http://hg.openjdk.java.net/openjfx/8u20/rt/, 
and I missed the b22 build but the repo isn’t reflecting that yet.

On Jul 8, 2014, at 2:02 PM, Tony Anecito  wrote:

> Thanks Kevin. I know why the media libraries need to not be present but not 
> what the stripped Info.plist means.
> 
> So when might b23 appear?
> 
> Thanks,
> -Tony
> 
> 
> 
> On Tuesday, July 8, 2014 1:53 PM, Kevin Rushforth 
>  wrote:
> 
> 
> 
> Danno will answer the first question (it is related to needing to omit 
> the media libraries). As to when it will appear, if it is approved for 
> inclusion into 8u20 it will be in b23.
> 
> -- Kevin
> 
> 
> 
> Tony Anecito wrote:
>> Hi Danno,
>> 
>> What do you mean by strips Info.plist? I am having a strange problem using 
>> b20 and wondering if it is related to what you meant by stripped Info.plist.
>> Also, what build will this be fixed in?
>> 
>> Thanks,
>> -Tony
>> 
>> 
>> 
>> On Monday, July 7, 2014 2:46 PM, "danno.fer...@shemnon.com" 
>>  wrote:
>>   
>> 
>> 
>> Changeset: 7398ae52202d
>> Author:shemnon
>> Date:  2014-07-07 10:51 -0600
>> URL:  http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/7398ae52202d
>> 
>> RT-37832: [packager] Mac App Store Bundler fails to strip jfxmedia.dylib and 
>> strips Info.plist
>> Summary: unit test for file verifications
>> 
>> ! 
>> modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacAppStoreBundlerTest.java
>>  

hg: openjfx/8u-dev/rt: RT-37832: [packager] Mac App Store Bundler fails to strip jfxmedia.dylib and strips Info.plist

[danno . ferrin]

Changeset: 7398ae52202d
Author:shemnon
Date:  2014-07-07 10:51 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/7398ae52202d

RT-37832: [packager] Mac App Store Bundler fails to strip jfxmedia.dylib and 
strips Info.plist
Summary: unit test for file verifications

! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacAppStoreBundlerTest.java

Review Request: RT-37832

[Danno Ferrin]

Kevin, Steve, Marty,

Please review the following. I consider this critical for 8u20 and request 
promotion to critical review.

Webrev: http://cr.openjdk.java.net/~shemnon/RT-37832/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-37832

Thanks,
—Danno

hg: openjfx/8u-dev/rt: 3 new changesets

[danno . ferrin]

Changeset: 56985c535d7a
Author:shemnon
Date:  2014-07-02 14:55 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/56985c535d7a

RT-37788: MacOSX Does not respect JVMUserOptions
Summary: Some tweaks to test code first

! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/linux/LinuxAppBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/linux/LinuxDebBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/linux/LinuxRpmBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacAppBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacAppStoreBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacDmgBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacPkgBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/windows/WinAppBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/windows/WinExeBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/windows/WinMsiBundlerTest.java
! modules/fxpackager/src/test/java/hello/TestPackager.java

Changeset: 8dfcc422ba56
Author:shemnon
Date:  2014-07-03 14:52 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8dfcc422ba56

RT-37788: MacOSX Does not respect JVMUserOptions
Summary: Make the mac launcher respect the established java.util.prefs patterns 
on Mac OSX
Include (disabled) unit tests.  These are disabled because they require manual 
execution and verification.

! modules/fxpackager/src/main/native/launcher/mac/main.m
! 
modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacAppBundlerTest.java

Changeset: 4e6634321740
Author:shemnon
Date:  2014-07-07 07:19 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/4e6634321740

RT-37832: [packager] Mac App Store Bundler fails to strip jfxmedia.dylib and 
strips Info.plist
Summary: Update the JDK Parameters prior to validating the app image bundler.  
This will get the right rules in place before they are evaluated by the child 
app image bundler's validation.

! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacAppStoreBundler.java

Re: Review Request: RT-37788

[Danno Ferrin]

Try #2, after running it through the the Xcode leak analyzer and unit testing 
(FYI keep your persistent domains lower case).

WebRev: http://cr.openjdk.java.net/~shemnon/RT-37788/webrev.01/rt.patch
JIRA: https://javafx-jira.kenai.com/browse/RT-37788

And let’s move further discussion to the JIRA issue.

On Jul 2, 2014, at 10:22 PM, Petr Pchelko  wrote:

> Hello, Danno.
> 
> I’ve noticed that you are leaking userDefaults and expandedOptions objects. 
> Adding autorelease to them would save you some memory.
> 
> With best regards. Petr.
> 
>> On Jul 3, 2014, at 1:43 AM, Danno Ferrin  wrote:
>> 
>> Yes, this has to be fixed in native code.  8u40 it is then.
>> 
>> I can make it cause a crash, but that starts with shooting myself in the 
>> foot, and not much can be done to fix it (by passing in bogus VM arguments).
>> 
>> 
>> On Jul 2, 2014, at 3:40 PM, Stephen F Northover 
>>  wrote:
>> 
>>> Personally, I wouldn't change any native code at this point unless it was 
>>> fixing a crash.  The review is for 8u40, correct?
>>> 
>>> Steve
>>> 
>>> On 2014-07-02, 5:38 PM, Chris Bensen wrote:
>>>> I’m not sure about for 8u20. Seems fairly straight forward, and your Obj-C 
>>>> seems as good as any Obj-C. My only complaint at the moment is the 
>>>> following:
>>>> 358 if ([pathParts count] > 2) {
>>>> 359 // for 3 or more steps, the domain is first.second.third and 
>>>> the keys are "/first/second/third/", "fourth/", "fifth/"... etc
>>>> 360 persistentDomain = [NSString stringWithFormat: @"%@.%@.%@", 
>>>> [pathParts objectAtIndex: 0],
>>>> 361 [pathParts objectAtIndex: 1], [pathParts 
>>>> objectAtIndex: 2]];
>>>> 362 
>>>> 363 [dictPath replaceObjectAtIndex: 0 withObject: [NSString 
>>>> stringWithFormat:@"/%@/%@/%@", [pathParts objectAtIndex: 0],
>>>> 364[pathParts 
>>>> objectAtIndex: 1], [pathParts objectAtIndex: 2]]];
>>>> 365 [dictPath removeObjectAtIndex: 2];
>>>> 366 [dictPath removeObjectAtIndex: 1];
>>>> 367 } else {
>>>> 368 // for 1 or two steps, the domain is first.second.third and 
>>>> the keys are "/", "first/", "second/"
>>>> 369 persistentDomain = @DEFAULT_JAVA_PREFS_DOMAIN;
>>>> 370 [dictPath insertObject: @"" atIndex:0];
>>>> 371 }
>>>> 
>>>> what if [pathParts count] is 0? I’d probably do a switch:
>>>> 
>>>> switch ([pathParts count]) {
>>>>  case 0:
>>>> //error
>>>> return/break;
>>>>  case 1:
>>>>  case 2:
>>>> 368 // for 1 or two steps, the domain is first.second.third and 
>>>> the keys are "/", "first/", "second/"
>>>> 369 persistentDomain = @DEFAULT_JAVA_PREFS_DOMAIN;
>>>> 370 [dictPath insertObject: @"" atIndex:0];
>>>>  default:
>>>> 359 // for 3 or more steps, the domain is first.second.third and 
>>>> the keys are "/first/second/third/", "fourth/", "fifth/"... etc
>>>> 360 persistentDomain = [NSString stringWithFormat: @"%@.%@.%@", 
>>>> [pathParts objectAtIndex: 0],
>>>> 361 [pathParts objectAtIndex: 1], [pathParts 
>>>> objectAtIndex: 2]];
>>>> 362 
>>>> 363 [dictPath replaceObjectAtIndex: 0 withObject: [NSString 
>>>> stringWithFormat:@"/%@/%@/%@", [pathParts objectAtIndex: 0],
>>>> 364[pathParts 
>>>> objectAtIndex: 1], [pathParts objectAtIndex: 2]]];
>>>> 365 [dictPath removeObjectAtIndex: 2];
>>>> 366 [dictPath removeObjectAtIndex: 1];
>>>> 
>>>> }
>>>> 
>>>> 
>>>> Make sense? Clear as mud?
>>>> 
>>>> Chris
>>>> 
>>>> 
>>>> On Jul 2, 2014, at 2:15 PM, Danno Ferrin  wrote:
>>>> 
>>>>> Chris, Kevin, Steve,
>>>>> 
>>>>> Please review this fix for RT-37788.  Since I am not an objective C any 
>>>>> comments are welcome.  Also, please consider if this is too much for an 
>>>>> 8u20 fix (the diff is against the current 8u40 codebase).
>>>>> 
>>>>> Webrev: http://cr.openjdk.java.net/~shemnon/RT-37788/webrev.00/
>>>>> JIRA: https://javafx-jira.kenai.com/browse/RT-37788
>>>>> 
>>>>> —Danno
> 

Re: Review Request: RT-37788

[Danno Ferrin]

Yes, this has to be fixed in native code.  8u40 it is then.

I can make it cause a crash, but that starts with shooting myself in the foot, 
and not much can be done to fix it (by passing in bogus VM arguments).


On Jul 2, 2014, at 3:40 PM, Stephen F Northover  
wrote:

> Personally, I wouldn't change any native code at this point unless it was 
> fixing a crash.  The review is for 8u40, correct?
> 
> Steve
> 
> On 2014-07-02, 5:38 PM, Chris Bensen wrote:
>> I’m not sure about for 8u20. Seems fairly straight forward, and your Obj-C 
>> seems as good as any Obj-C. My only complaint at the moment is the following:
>>  358 if ([pathParts count] > 2) {
>>  359 // for 3 or more steps, the domain is first.second.third and 
>> the keys are "/first/second/third/", "fourth/", "fifth/"... etc
>>  360 persistentDomain = [NSString stringWithFormat: @"%@.%@.%@", 
>> [pathParts objectAtIndex: 0],
>>  361 [pathParts objectAtIndex: 1], [pathParts 
>> objectAtIndex: 2]];
>>  362 
>>  363 [dictPath replaceObjectAtIndex: 0 withObject: [NSString 
>> stringWithFormat:@"/%@/%@/%@", [pathParts objectAtIndex: 0],
>>  364[pathParts 
>> objectAtIndex: 1], [pathParts objectAtIndex: 2]]];
>>  365 [dictPath removeObjectAtIndex: 2];
>>  366 [dictPath removeObjectAtIndex: 1];
>>  367 } else {
>>  368 // for 1 or two steps, the domain is first.second.third and the 
>> keys are "/", "first/", "second/"
>>  369 persistentDomain = @DEFAULT_JAVA_PREFS_DOMAIN;
>>  370 [dictPath insertObject: @"" atIndex:0];
>>  371 }
>> 
>> what if [pathParts count] is 0? I’d probably do a switch:
>> 
>> switch ([pathParts count]) {
>>   case 0:
>>  //error
>>  return/break;
>>   case 1:
>>   case 2:
>>  368 // for 1 or two steps, the domain is first.second.third and the 
>> keys are "/", "first/", "second/"
>>  369 persistentDomain = @DEFAULT_JAVA_PREFS_DOMAIN;
>>  370 [dictPath insertObject: @"" atIndex:0];
>>   default:
>>  359 // for 3 or more steps, the domain is first.second.third and 
>> the keys are "/first/second/third/", "fourth/", "fifth/"... etc
>>  360 persistentDomain = [NSString stringWithFormat: @"%@.%@.%@", 
>> [pathParts objectAtIndex: 0],
>>  361 [pathParts objectAtIndex: 1], [pathParts 
>> objectAtIndex: 2]];
>>  362 
>>  363 [dictPath replaceObjectAtIndex: 0 withObject: [NSString 
>> stringWithFormat:@"/%@/%@/%@", [pathParts objectAtIndex: 0],
>>  364[pathParts 
>> objectAtIndex: 1], [pathParts objectAtIndex: 2]]];
>>  365 [dictPath removeObjectAtIndex: 2];
>>  366 [dictPath removeObjectAtIndex: 1];
>> 
>> }
>> 
>> 
>> Make sense? Clear as mud?
>> 
>> Chris
>> 
>> 
>> On Jul 2, 2014, at 2:15 PM, Danno Ferrin  wrote:
>> 
>>> Chris, Kevin, Steve,
>>> 
>>> Please review this fix for RT-37788.  Since I am not an objective C any 
>>> comments are welcome.  Also, please consider if this is too much for an 
>>> 8u20 fix (the diff is against the current 8u40 codebase).
>>> 
>>> Webrev: http://cr.openjdk.java.net/~shemnon/RT-37788/webrev.00/
>>> JIRA: https://javafx-jira.kenai.com/browse/RT-37788
>>> 
>>> —Danno
>> 
> 

Review Request: RT-37788

[Danno Ferrin]

Chris, Kevin, Steve,

Please review this fix for RT-37788.  Since I am not an objective C any 
comments are welcome.  Also, please consider if this is too much for an 8u20 
fix (the diff is against the current 8u40 codebase).

Webrev: http://cr.openjdk.java.net/~shemnon/RT-37788/webrev.00/
JIRA: https://javafx-jira.kenai.com/browse/RT-37788

—Danno

Re: Is Bundler now working for command line parameters?

[Danno Ferrin]

This won’t be fixed until 8u40.

What platforms are you targeting?  Mac, Linux, Windows?


On Jul 2, 2014, at 2:35 PM, Tony Anecito  wrote:

> Hi Danno,
> 
> Is b20 have the fix for command line parameters that should get passed to the 
> "args" for the static main method? And if so how do I do that via the 
> deployfx ant task?
> 
> Thanks,
> -Tony

[8u20] Review Request for RT-37732

[Danno Ferrin]

Hello Steve, Kevin:

I’de like to get this fix pushed into 8u20.

mercurial: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/bc10f48ef71f
jira: https://javafx-jira.kenai.com/browse/RT-37732

Small, self contained, limited impact, code new to 8u20, and it will make a 
huge difference for the assumptions API processors can make.

—Danno

hg: openjfx/8u-dev/rt: RT-37732:[packager] Default argument lambdas should be well behaved

[danno . ferrin]

Changeset: bc10f48ef71f
Author:shemnon
Date:  2014-06-26 13:30 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/bc10f48ef71f

RT-37732:[packager] Default argument lambdas should be well behaved
Summary: Deal with the case of a null identifier.
Add unit tests as well.

! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/StandardBundlerParam.java
! modules/fxpackager/src/test/java/com/oracle/tools/packager/BundlersTest.java

hg: openjfx/8u-dev/rt: RT-37599: Creation of a DMG from an APP is broken (scpt fails)

[danno . ferrin]

Changeset: 296d878c295d
Author:shemnon
Date:  2014-06-25 14:25 -0600
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/296d878c295d

RT-37599: Creation of a DMG from an APP is broken (scpt fails)
Summary: Re-work script to depend on posix file name instead of finder 
presented name.

! 
modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacDmgBundler.java
! 
modules/fxpackager/src/main/resources/com/oracle/tools/packager/mac/DMGsetup.scpt

Re: New bundler in 8u20 question...

[Danno Ferrin]

I was thinking DMG bundler there for a moment.  The PKG bundler should be 
installing in the /Applicaitons folder and there shouldn’t be any way to alter 
that.  So this sounds like a bug to me.  Since we are going into M5 tonight at 
1am I will need a bug to get this past the gatekeeping process.  Could you open 
one up explaining what you need to happen?  Since the PKG bundler is new this 
should be easier to pull off since there are not nearly as many regressions to 
watch out for.

On Jun 15, 2014, at 8:01 PM, Tony Anecito  wrote:

> Thanks Danno I do not use netbeans just Ant script for my build. So any way 
> to set the javaFX Deploy ant script to tell the pkg file to deploy to the 
> applications folder?
> 
> Thanks Again,
> -Tony
> 
> 
> On Sunday, June 15, 2014 3:36 PM, Danno Ferrin  
> wrote:
> 
> 
> 
> On Jun 15, 2014, at 11:32 AM, Tony Anecito  wrote:
> 
>> Thanks Danno I figured there might be new arguments. And also thanks for 
>> working on making it easier for all of us.
>> I did notice that the pkg file created did not install into the applications 
>> folder. How does one get it to do that? Is there a new argument for that 
>> also?
> 
> This is the “SystemWide” argument, which IIRC netbeans sets to false by 
> default, this is NetBeans doing and not the packager.  I still don’t 
> understand why they invert that default.  And it’s a pain to configure.
> 
> On your project, RMC and select properties.  Go to build/deployment and turn 
> on the advanced JavaFX properties.  There is a scary dialog about changing 
> the project files format.  Save a backup first.
> 
> Now it re-loads the project.  Go to the same dialog and about 2/3 of the way 
> down is a checkbox “Install Permanently,” check it.
> 
> If you use the CLI or the Ant files w/o NetBeans help it is set to system 
> wide by default, it is the JavaFX project (which makes sensible decisions for 
> a webstart-centric app) that makes things confusing.
> 
>>  
>> Thanks,
>> -Tony 
>> 
>> 
>> On Sunday, June 15, 2014 9:48 AM, Mike Hearn  wrote:
>> 
>> 
>> Does the new bundler still create DMGs as well?
>> 
>>  --MAS.pkg where the -MAS variant is for Mac App Store, 
>> this will show up in next weeks build.
>> 
>> 
>> Could I suggest -AppStore instead of -MAS, which is a rather opaque acronym. 
>> 
>> 
> 
> 
> 
> 

Re: New bundler in 8u20 question...

[Danno Ferrin]

On Jun 15, 2014, at 11:32 AM, Tony Anecito  wrote:

> Thanks Danno I figured there might be new arguments. And also thanks for 
> working on making it easier for all of us.
> I did notice that the pkg file created did not install into the applications 
> folder. How does one get it to do that? Is there a new argument for that also?

This is the “SystemWide” argument, which IIRC netbeans sets to false by 
default, this is NetBeans doing and not the packager.  I still don’t understand 
why they invert that default.  And it’s a pain to configure.

On your project, RMC and select properties.  Go to build/deployment and turn on 
the advanced JavaFX properties.  There is a scary dialog about changing the 
project files format.  Save a backup first.

Now it re-loads the project.  Go to the same dialog and about 2/3 of the way 
down is a checkbox “Install Permanently,” check it.

If you use the CLI or the Ant files w/o NetBeans help it is set to system wide 
by default, it is the JavaFX project (which makes sensible decisions for a 
webstart-centric app) that makes things confusing.

>  
> Thanks,
> -Tony 
> 
> 
> On Sunday, June 15, 2014 9:48 AM, Mike Hearn  wrote:
> 
> 
> Does the new bundler still create DMGs as well?
> 
>  --MAS.pkg where the -MAS variant is for Mac App Store, 
> this will show up in next weeks build.
> 
> 
> Could I suggest -AppStore instead of -MAS, which is a rather opaque acronym. 
> 
> 

Re: New bundler in 8u20 question...

[Danno Ferrin]

On Jun 15, 2014, at 9:48 AM, Mike Hearn  wrote:

> Does the new bundler still create DMGs as well?

Yes.

> 
>  --MAS.pkg where the -MAS variant is for Mac App Store, 
> this will show up in next weeks build.
> 
> Could I suggest -AppStore instead of -MAS, which is a rather opaque acronym. 

Sure.

Re: New bundler in 8u20 question...

[Danno Ferrin]

Now that ramp down phase 2 is upon us I was going to post a blog post about it 
this week, but looks like there are some burning questions...
On Jun 14, 2014, at 8:52 PM, Tony Anecito  wrote:

> Hi All,
>  
> The new bundler in 8u20 seems to create a .pkg file.

It can create two pkg files.  One is the normal PKG wizard installer, like you 
see when you install Java.  The other pkg installer crease a Mac App Store 
Ready pkg that ban be uploaded via iTunes connect.  The problem is right now 
they will have the same name and overwrite each other, so later today I’ll 
submit a patch to make the packages default file name to be 
-.pkg and --MAS.pkg where the -MAS variant 
is for Mac App Store, this will show up in next weeks build.

> I am wondering if that is also codesigned via apple codesign command and if 
> so how does it find the entitlements file?

If you have your Apple keys downloaded in the typical place the signing will be 
automatic.  This also extends to Gatekeeper signing.  The bundle arguments to 
set are…

For gatekeeper you can set one or both of these
mac.signing-key-developer-id-app - for .app files for gatekeeper
mac.signing-key-developer-id-installer - for .pkg files for gatekeeper

For mac app store you can set two arguments 
mac.signing-key-app - for the MAS .app file
mac.signing-key-pkg - for the MAS .pkg file

The defaults are "Developer ID Application: “, "Developer ID Installer: “, "3rd 
Party Mac Developer Application: “, and "3rd Party Mac Developer Installer: “ 
respectively (as of next weeks build).  So if you have your keys in the typical 
place the signing is automatic.  If you have multiple keys following the 
default names you can set "mac.signing-key-user-name” to append a user name 
after each of the defaults, or manually set all of them.

As for entitlements, set a bundle parameter 'mac.app-store-entitlements’ to the 
location of your entitlements file.  This is relative to the local file system 
of the build tool.  By default the bundler adds a sandbox entitlement with no 
other grants.  So if you do anything special (such as access a web service) you 
will need to provide a file.

> So is the goal of the new bundler to replace ALL the manual steps Danno 
> mentioned previously for it to be ready for the Apple iTunes store?
>  

That’s the goal.  In fact, the manual steps are basically the steps the 
MacAppStoreBundler goes through, that’s how I proved they work.

I mentioned bundler arguments. These are new in the 8u20 bundler.  To set them 
you can use the -B flag in the CLI or the  int he ant 
build.  I’m working on the Gradle and Maven plugins but won’t be releasing 
those for a month or so, but most of the code is in the relevant 
bitbucket/github reps.

For example, you would want to set at least…

fxpackager -native mac.appStore 
-Bmac.app-store-entitlements=src/deploy/package/MyEntitlements.entitlements (… 
rest of arguments…)

or


  
  


But you may want to set the other signing key arguments as well.

Re: Large Image Export

[Danno Ferrin]

So the limitation is in the snapshot code, not the target image code?  This
is actually a feasible workaround, so 8u40 would be grand but 9 is also
just fine.

Also, is 4K the lowest the texture size max will be?  Or is there some API
to query it?


On Fri, Jun 13, 2014 at 9:38 AM, Kevin Rushforth  wrote:

>  This is RT-22073 <https://javafx-jira.kenai.com/browse/RT-22073> which
> is currently targeted for 9, but could be moved into 8u20 if there was
> enough demand to fix it. The (rather ugly) app-level workaround is to break
> the operation up into 4Kx4K tiles, and render the tiles in a loop
> specifying the appropriate viewport and translation via ShapshotParams.
>
> -- Kevin
>
>
>
>
> Danno Ferrin wrote:
>
> While working on a fun project I discovered that the Image Export limits
> the size of the export textures, mostly depending on your graphics stack.
>  Here's one example:
>
> java.lang.RuntimeException: Requested texture dimensions (20581x245)
> require dimensions (0x245) that exceed maximum texture size (16384)
> at com.sun.prism.es2.ES2RTTexture.create(ES2RTTexture.java:220)
> at
> com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:106)
> at
> com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:102)
> at
> com.sun.javafx.tk.quantum.QuantumToolkit$QuantumImage.getRT(QuantumToolkit.java:1210)
> at com.sun.javafx.tk.quantum.QuantumToolkit$18.run(QuantumToolkit.java:1345)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:129)
>
> This is on a mid-2012 Mac Book Air, and the MacGLConext looks to limit
> dimensions to 2^14.
>
> Is there anything I can do other than making sure my nodes don't get bigger
> than 16K on one side?  I've tried setting a transform on the snapshot and
> zooming it below 16k, but it still gets the same exception with he same
> dimensions.
>
> --Danno
>
>
>

Large Image Export

[Danno Ferrin]

While working on a fun project I discovered that the Image Export limits
the size of the export textures, mostly depending on your graphics stack.
 Here's one example:

java.lang.RuntimeException: Requested texture dimensions (20581x245)
require dimensions (0x245) that exceed maximum texture size (16384)
at com.sun.prism.es2.ES2RTTexture.create(ES2RTTexture.java:220)
at
com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:106)
at
com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:102)
at
com.sun.javafx.tk.quantum.QuantumToolkit$QuantumImage.getRT(QuantumToolkit.java:1210)
at com.sun.javafx.tk.quantum.QuantumToolkit$18.run(QuantumToolkit.java:1345)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:129)

This is on a mid-2012 Mac Book Air, and the MacGLConext looks to limit
dimensions to 2^14.

Is there anything I can do other than making sure my nodes don't get bigger
than 16K on one side?  I've tried setting a transform on the snapshot and
zooming it below 16k, but it still gets the same exception with he same
dimensions.

--Danno

Re: Bundler question for Mac OS X...

[Danno Ferrin]

It does change the sub-menu items (Hide /Quit ), at least the 8u20 
toolchain does.  I would expect the 8u5 toolchain to change it too because it 
looks the same, but I haven’t worked on those builds recently.


On Jun 11, 2014, at 8:05 AM, Tony Anecito  wrote:

> I will try your suggestion to see if the sub-menu items name changes with 
> what you sugggested.
>  
> Thanks,
> -Tony 
> 
> 
> On , Tony Anecito  wrote:
> 
> 
>  Hi,
>  
> The name attribute affects the main menu item but not the sub-menu items. Not 
> sure if you understood what I meant by sub-menu items. It would be better if 
> the sub-menu items did not use the starting/launcher class name. I even found 
> examples googleing where java main.startupclassname was shown for sub-menu 
> items.
>  
> Apple iTunes store will reject java apps becuase of this issue. They want the 
> app name to match everywhere on the app including the sub-menu item names.
>  
> Thanks,
> -Tony
> 
> 
> On Wednesday, June 11, 2014 7:50 AM, Danno Ferrin  
> wrote:
> 
> 
> This will be upgraded in the 8u20 release.
> 
> For pre8u20 in the ant script the menu bar name is the name attribute from 
> the application element.
> 
> 
>   
>   
>   
> 
> 
> (This will still work in 8u20, if it doesn’t it is a bug to me I will fix).
> 
> The down side is that some of those value have double use when using multiple 
> platforms.  For example the id attribute is also the UUID for MSI bundles.  
> The name is also the name of the launcher file too, and pre 8u20 they are 
> tied together (unless you do a drop in resource to manually fix the 
> identifier).
> 
> Starting with 8u20 you can specify bundle params, and I have done my best to 
> eliminate the overlapping values, or at least allow you to set specific 
> values that will fall back to overlapping values.
> 
> 
>   
>value=“com.example.your.mac.App”/>
>   
>   
> 
> 
> Since the windows bundlers don’t understand those arguments they will ignore 
> them.  And the bundle name can be different from the launcher name now as 
> well.
> 
> On Jun 11, 2014, at 4:16 AM, Anthony Petrov  wrote:
> 
> > Hi Tony,
> > 
> > I don't know the exact syntax for the FX deploy script (is it the -title or 
> > -name option for the javafxpackager [1] ?), however [2] suggests that the 
> > CFBundleName key in Info.plist can be used to set the application name. I 
> > can confirm that Glass reads the value and assigns it to the application 
> > name. The Quit menu item then uses this name for its text label.
> > 
> > Does setting the CFBundleName work for you?
> > 
> > [1] http://docs.oracle.com/javafx/2/deployment/javafxpackager.htm
> > 
> > [2] https://javafx-jira.kenai.com/browse/RT-18563
> > 
> > --
> > best regards,
> > Anthony
> > 
> > On 6/11/2014 7:54 AM, Tony Anecito wrote:
> >> Hi All,
> >> 
> >> I noticed the menu bar for OS X is probably using my class name that has 
> >> the static main in it. How do I override that in the JavFX Deploy ant 
> >> script? The About, Hide and Quit sub-menu items are using a different name 
> >> than what I want. The main menu item is correct.
> >> 
> >> Thanks!
> >> Tony
> >> 
> 
> 
> 
> 

Re: Bundler question for Mac OS X...

[Danno Ferrin]

This will be upgraded in the 8u20 release.

For pre8u20 in the ant script the menu bar name is the name attribute from the 
application element.


  
  
  


(This will still work in 8u20, if it doesn’t it is a bug to me I will fix).

The down side is that some of those value have double use when using multiple 
platforms.  For example the id attribute is also the UUID for MSI bundles.  The 
name is also the name of the launcher file too, and pre 8u20 they are tied 
together (unless you do a drop in resource to manually fix the identifier).

Starting with 8u20 you can specify bundle params, and I have done my best to 
eliminate the overlapping values, or at least allow you to set specific values 
that will fall back to overlapping values.


  
  
  
  


Since the windows bundlers don’t understand those arguments they will ignore 
them.  And the bundle name can be different from the launcher name now as well.

On Jun 11, 2014, at 4:16 AM, Anthony Petrov  wrote:

> Hi Tony,
> 
> I don't know the exact syntax for the FX deploy script (is it the -title or 
> -name option for the javafxpackager [1] ?), however [2] suggests that the 
> CFBundleName key in Info.plist can be used to set the application name. I can 
> confirm that Glass reads the value and assigns it to the application name. 
> The Quit menu item then uses this name for its text label.
> 
> Does setting the CFBundleName work for you?
> 
> [1] http://docs.oracle.com/javafx/2/deployment/javafxpackager.htm
> 
> [2] https://javafx-jira.kenai.com/browse/RT-18563
> 
> --
> best regards,
> Anthony
> 
> On 6/11/2014 7:54 AM, Tony Anecito wrote:
>> Hi All,
>> 
>> I noticed the menu bar for OS X is probably using my class name that has the 
>> static main in it. How do I override that in the JavFX Deploy ant script? 
>> The About, Hide and Quit sub-menu items are using a different name than what 
>> I want. The main menu item is correct.
>> 
>> Thanks!
>> Tony
>> 

Re: Extending a Region to create a JUNG Layout

[Danno Ferrin]

Except the license.txt page points to the OSI page that is... BSD 2 Clause.

Here's the zoom pane as BSD 2 clause...

https://github.com/shemnon/FollowTheBitcoin/commit/effd601965875fec8891f8202afea1f84f1daf54

If you really want me to add the non-endorsement clause I can, but it is
kind of awkwardly worded for individual contributors.



On Sun, Jun 1, 2014 at 10:49 PM, Jeffrey Guenther <
guenther.jeff...@gmail.com> wrote:

> BSD - 3 Clause - http://jung.sourceforge.net/license.txt
>
>
> On Sat, May 31, 2014 at 6:17 PM, Danno Ferrin 
> wrote:
>
>> The new matrix classes exposed in JavaFX 8 help a lot.
>>
>> I'll re-license it BSD.  2 clause, 3 clause, new?  Can you point me to a
>> preferred header?
>>
>>
>> On Fri, May 30, 2014 at 6:11 PM, Jeffrey Guenther <
>> guenther.jeff...@gmail.com> wrote:
>>
>>> Danno, thanks! It works super well and has so little code!
>>>
>>> If I use the class in my JUNG work, I need a BSD license. The rest of
>>> that codebase is BSD already. I’ll contact you off list if I go that
>>> direction. Right now, I’m trying to get my head wrapped around what it
>>> would take to modernize JUNG.
>>>
>>>
>>> On May 30, 2014, at 4:20 PM, Danno Ferrin 
>>> wrote:
>>>
>>> > You may find this class valuable, it is a pane that listens to zoom
>>> and mouse scroll events in a group, essential for large graphs:
>>> >
>>> >
>>> https://github.com/shemnon/FollowTheBitcoin/blob/master/src/main/groovy/com/shemnon/btc/view/ZoomPane.java
>>> >
>>> > I haven't had time to harden it and componentize it into a standalone
>>> release.  If you don't like the license let me know what license you would
>>> like.
>>> >
>>> > --Danno
>>> >
>>> > - Original Message -
>>> > From: sven.reim...@gmail.com
>>> > To: guenther.jeff...@gmail.com
>>> > Cc: openjfx-dev@openjdk.java.net
>>> > Sent: Friday, May 30, 2014 1:27:48 AM GMT -07:00 US/Canada Mountain
>>> > Subject: Re: Extending a Region to create a JUNG Layout
>>> >
>>> > Hi Jeffrey,
>>> >
>>> > I did some prototyping with Jung JavaFX and Java 8, the results are
>>> here
>>> >
>>> > https://bitbucket.org/sreimers/jung8
>>> >
>>> > It uses gradle to build and contains an additional library for jungfx.
>>> >
>>> > Enjoy
>>> >
>>> > -Sven
>>> >
>>> >
>>> > On Fri, May 30, 2014 at 8:44 AM, Jeffrey Guenther <
>>> > guenther.jeff...@gmail.com> wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> I'm in the midst of exploring how I might port JUNG(
>>> >> http://jung.sourceforge.net/index.html) to JavaFX. JUNG is a
>>> graph/layout
>>> >> tool my lab uses for some of their data visualizations. With the
>>> release of
>>> >> JavaFX 2, we've started building our prototypes in JavaFX.
>>> >>
>>> >> Rather than use the JFXSwingPanel, I want to try modifying the JUNG
>>> to work
>>> >> "natively" in JavaFX. In the long term, I'd like to see JUNG ported
>>> >> completely to JavaFX using properties, CSS and the like.
>>> >>
>>> >> I've built a quick demo (
>>> >> https://gist.github.com/jrguenther/9d0c37329f9928a2b56e) and need
>>> help
>>> >> going forward. I've been reading the docs and hitting google, but I
>>> think I
>>> >> need more info.
>>> >>
>>> >> Can someone point me to a detailed explanation of how to extend
>>> Region to
>>> >> create my own layout?
>>> >> In particular, how can I get a region to relayout it's children when
>>> it's
>>> >> being resized?
>>> >> When does a the region's parent call layoutChildren()?
>>> >> If the height and width of the region are set to Double.MAX_VALUE
>>> >> indicating the area can grow infinitely, how does the region know
>>> what size
>>> >> to set itself to?
>>> >>
>>> >> Thanks,
>>> >> Jeff
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Sven Reimers
>>> >
>>> > * Senior Expert Software Architect
>>> > * NetBeans Dream Team Member: http://dreamteam.netbeans.org
>>> > * Community Leader  NetBeans: http://community.java.net/netbeans
>>> >  Desktop Java:
>>> > http://community.java.net/javadesktop
>>> > * JUG Leader JUG Bodensee: http://www.jug-bodensee.de
>>> > * Duke's Choice Award Winner 2009
>>> > * Blog: https://www.java.net//blog/sven
>>> >
>>> > * XING: https://www.xing.com/profile/Sven_Reimers8
>>> > * LinkedIn: http://www.linkedin.com/in/svenreimers
>>> >
>>> > Join the NetBeans Groups:
>>> > * XING: http://www.xing.com/group-20148.82db20
>>> > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home
>>> > * LinkedIn: http://www.linkedin.com/groups?gid=1860468
>>> >   http://www.linkedin.com/groups?gid=107402
>>> >   http://www.linkedin.com/groups?gid=1684717
>>> > * Oracle: https://mix.oracle.com/groups/18497
>>>
>>>
>>
>

Re: Extending a Region to create a JUNG Layout

[Danno Ferrin]

The new matrix classes exposed in JavaFX 8 help a lot.

I'll re-license it BSD.  2 clause, 3 clause, new?  Can you point me to a
preferred header?


On Fri, May 30, 2014 at 6:11 PM, Jeffrey Guenther <
guenther.jeff...@gmail.com> wrote:

> Danno, thanks! It works super well and has so little code!
>
> If I use the class in my JUNG work, I need a BSD license. The rest of that
> codebase is BSD already. I’ll contact you off list if I go that direction.
> Right now, I’m trying to get my head wrapped around what it would take to
> modernize JUNG.
>
>
> On May 30, 2014, at 4:20 PM, Danno Ferrin  wrote:
>
> > You may find this class valuable, it is a pane that listens to zoom and
> mouse scroll events in a group, essential for large graphs:
> >
> >
> https://github.com/shemnon/FollowTheBitcoin/blob/master/src/main/groovy/com/shemnon/btc/view/ZoomPane.java
> >
> > I haven't had time to harden it and componentize it into a standalone
> release.  If you don't like the license let me know what license you would
> like.
> >
> > --Danno
> >
> > - Original Message -
> > From: sven.reim...@gmail.com
> > To: guenther.jeff...@gmail.com
> > Cc: openjfx-dev@openjdk.java.net
> > Sent: Friday, May 30, 2014 1:27:48 AM GMT -07:00 US/Canada Mountain
> > Subject: Re: Extending a Region to create a JUNG Layout
> >
> > Hi Jeffrey,
> >
> > I did some prototyping with Jung JavaFX and Java 8, the results are here
> >
> > https://bitbucket.org/sreimers/jung8
> >
> > It uses gradle to build and contains an additional library for jungfx.
> >
> > Enjoy
> >
> > -Sven
> >
> >
> > On Fri, May 30, 2014 at 8:44 AM, Jeffrey Guenther <
> > guenther.jeff...@gmail.com> wrote:
> >
> >> Hi,
> >>
> >> I'm in the midst of exploring how I might port JUNG(
> >> http://jung.sourceforge.net/index.html) to JavaFX. JUNG is a
> graph/layout
> >> tool my lab uses for some of their data visualizations. With the
> release of
> >> JavaFX 2, we've started building our prototypes in JavaFX.
> >>
> >> Rather than use the JFXSwingPanel, I want to try modifying the JUNG to
> work
> >> "natively" in JavaFX. In the long term, I'd like to see JUNG ported
> >> completely to JavaFX using properties, CSS and the like.
> >>
> >> I've built a quick demo (
> >> https://gist.github.com/jrguenther/9d0c37329f9928a2b56e) and need help
> >> going forward. I've been reading the docs and hitting google, but I
> think I
> >> need more info.
> >>
> >> Can someone point me to a detailed explanation of how to extend Region
> to
> >> create my own layout?
> >> In particular, how can I get a region to relayout it's children when
> it's
> >> being resized?
> >> When does a the region's parent call layoutChildren()?
> >> If the height and width of the region are set to Double.MAX_VALUE
> >> indicating the area can grow infinitely, how does the region know what
> size
> >> to set itself to?
> >>
> >> Thanks,
> >> Jeff
> >>
> >
> >
> >
> > --
> > Sven Reimers
> >
> > * Senior Expert Software Architect
> > * NetBeans Dream Team Member: http://dreamteam.netbeans.org
> > * Community Leader  NetBeans: http://community.java.net/netbeans
> >  Desktop Java:
> > http://community.java.net/javadesktop
> > * JUG Leader JUG Bodensee: http://www.jug-bodensee.de
> > * Duke's Choice Award Winner 2009
> > * Blog: https://www.java.net//blog/sven
> >
> > * XING: https://www.xing.com/profile/Sven_Reimers8
> > * LinkedIn: http://www.linkedin.com/in/svenreimers
> >
> > Join the NetBeans Groups:
> > * XING: http://www.xing.com/group-20148.82db20
> > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home
> > * LinkedIn: http://www.linkedin.com/groups?gid=1860468
> >   http://www.linkedin.com/groups?gid=107402
> >   http://www.linkedin.com/groups?gid=1684717
> > * Oracle: https://mix.oracle.com/groups/18497
>
>

Re: Extending a Region to create a JUNG Layout

[Danno Ferrin]

You may find this class valuable, it is a pane that listens to zoom and mouse 
scroll events in a group, essential for large graphs:

https://github.com/shemnon/FollowTheBitcoin/blob/master/src/main/groovy/com/shemnon/btc/view/ZoomPane.java

I haven't had time to harden it and componentize it into a standalone release.  
If you don't like the license let me know what license you would like.

--Danno

- Original Message -
From: sven.reim...@gmail.com
To: guenther.jeff...@gmail.com
Cc: openjfx-dev@openjdk.java.net
Sent: Friday, May 30, 2014 1:27:48 AM GMT -07:00 US/Canada Mountain
Subject: Re: Extending a Region to create a JUNG Layout

Hi Jeffrey,

I did some prototyping with Jung JavaFX and Java 8, the results are here

https://bitbucket.org/sreimers/jung8

It uses gradle to build and contains an additional library for jungfx.

Enjoy

-Sven


On Fri, May 30, 2014 at 8:44 AM, Jeffrey Guenther <
guenther.jeff...@gmail.com> wrote:

> Hi,
>
> I'm in the midst of exploring how I might port JUNG(
> http://jung.sourceforge.net/index.html) to JavaFX. JUNG is a graph/layout
> tool my lab uses for some of their data visualizations. With the release of
> JavaFX 2, we've started building our prototypes in JavaFX.
>
> Rather than use the JFXSwingPanel, I want to try modifying the JUNG to work
> "natively" in JavaFX. In the long term, I'd like to see JUNG ported
> completely to JavaFX using properties, CSS and the like.
>
> I've built a quick demo (
> https://gist.github.com/jrguenther/9d0c37329f9928a2b56e) and need help
> going forward. I've been reading the docs and hitting google, but I think I
> need more info.
>
> Can someone point me to a detailed explanation of how to extend Region to
> create my own layout?
> In particular, how can I get a region to relayout it's children when it's
> being resized?
> When does a the region's parent call layoutChildren()?
> If the height and width of the region are set to Double.MAX_VALUE
> indicating the area can grow infinitely, how does the region know what size
> to set itself to?
>
> Thanks,
> Jeff
>



-- 
Sven Reimers

* Senior Expert Software Architect
* NetBeans Dream Team Member: http://dreamteam.netbeans.org
* Community Leader  NetBeans: http://community.java.net/netbeans
  Desktop Java:
http://community.java.net/javadesktop
* JUG Leader JUG Bodensee: http://www.jug-bodensee.de
* Duke's Choice Award Winner 2009
* Blog: https://www.java.net//blog/sven

* XING: https://www.xing.com/profile/Sven_Reimers8
* LinkedIn: http://www.linkedin.com/in/svenreimers

Join the NetBeans Groups:
* XING: http://www.xing.com/group-20148.82db20
* NUGM: http://haug-server.dyndns.org/display/NUGM/Home
* LinkedIn: http://www.linkedin.com/groups?gid=1860468
   http://www.linkedin.com/groups?gid=107402
   http://www.linkedin.com/groups?gid=1684717
* Oracle: https://mix.oracle.com/groups/18497

Re: Roadmap for javafxpackager?

[Danno Ferrin]

The icon can be customized prior to the 8u20 release via magic file locations:

http://docs.oracle.com/javafx/2/deployment/self-contained-packaging.htm#BCGICFDB

You can customize both the app icon as well as the DMG icon, and the backing 
image.  The main issue is you need to create an icns yourself.  Another option 
is to use the gradle plugin I wrote that will create the ICNS for you out of 
PNG images.

File Association support is not coming in 8u20, I will take this message as a 
vote to add it to a later release.


On May 14, 2014, at 3:43 PM, Mike Hearn  wrote:

> I've been looking around for the best way to distribute my app.
> Javafxpackager is a big leap over what Java provided before (nothing) but
> it's still pretty basic. I'm wondering if there's a plan or roadmap for
> improving it. For instance I made a Mac DMG (it works, yay!) but I had to
> manually replace the default icon file: there's apparently no way to adjust
> that. Also, no support for configuring file associations etc.
> 
> It looks like to get something sophisticated like the Scene Builder
> packaging still requires a lot of platform specific work.

Code Review Request For RT-37122: Css2Bin cannot overwrite existing writable field

[Danno Ferrin]

David, Kevin,

Please review  the proposed fix

JIRA: https://javafx-jira.kenai.com/browse/RT-37122
Webrev: http://cr.openjdk.java.net/~shemnon/RT-37122/webrev.00/

—Danno

Re: How to deploy JavaFX application writen in JavaScript unsing Nashorn

[Danno Ferrin]

The JJS command line tool delegates to jdk.nashorn.tools.Shell, with a lot of 
custom command line switches.  Some of these command line switches also do 
custom things, particularly the -fx flag.  The problem with using the Shell 
class as the main for javapackager its that currently we don’t support command 
line arguments not passed in by the user.  So your best bet is to write a main 
class that passes in {“apps_all.js", “-fx-“, “.”} to the static main method of 
Shell, note all the custom command line arguments the shell script passes in, 
and hanse the packager set those as jvmArgs.

On May 7, 2014, at 5:26 AM, Mike Hearn  wrote:

> It's probably easiest to have a tiny Java app that just loads the JS files
> from resources in the JAR and runs it via Nashorn directly. Then all
> existing tools like jfxpackager, JWrapper etc can treat it like a Java app.
> 
> 
> On Wed, May 7, 2014 at 3:30 AM, Bilal Soidik  wrote:
> 
>> Hi!
>> As you know, we can write JavaFX application in JavaScript using Nashorn
>> Engine, but I have to run application with command line like: > jjs
>> app_all.js -fx .
>> So I wont know how can I deploy application that let me click on and lunch
>> it or make a self-contained application packaging using JDK 7(Update 6 or
>> later) packaging tools
>> 
>> --
>> *Bilal Soidiki Mpapandza*
>> *Etudiant en Master Spé. Qualité du Logiciel, FS UIT*
>> *Ingénieur logiciel et Développeur Java, C/C++,.NET et PHP*
>> *Tél.*:*(+212) 602746546*
>> *Blog   *:* http://la-lune-1.blogspot.com
>>   *
>> *Twitter   *:* bilaalsoidik*
>> *Skype   *:* bilalsoidik*
>>