[10] Review request: 8187059 Update VS Projects

2017-08-31 Thread Chris Bensen
Victor,

Please review this change to upgrade the native projects to the latest version 
of VS 2017:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8187059
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8187059/webrev.00/

Chris


[10] Review request: 8186237 Refactor jdk.packager to legacy package

2017-08-16 Thread Chris Bensen
Victor,

Please review this refactor to get ready for the new CLI.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8186237
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8186237/webrev.00/

Chris


[10] Review request: 8184769 Static Link to SHGetKnownFolderPath

2017-07-17 Thread Chris Bensen
Victor,

Please review this change to remove the LoadLibray.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8184769
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8184769/webrev.00/

Chris


[10] Review request: 8183246 Remove Platform::GetSystemJRE()

2017-07-07 Thread Chris Bensen
Victor,

Please review this change to remove the dead code related to acquiring the 
system JRE for a packaged app.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8183246
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8183246/webrev.00/

Chris


[10] Review request: 8091418 Evaluate TODOs in code, either removing or filing issues as appropriate

2017-06-30 Thread Chris Bensen
Victor,

Please review these changes related to the TODOs and FIXMEs in the java 
packager code.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8091418
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8091418/webrev.00/

Chris


[10] Review request: 8182778 Debug JDK Additions

2017-06-26 Thread Chris Bensen
Kevin, Victor,

Please review these additions to the Java Packager debug JDK. This change will 
bundle the jdk.packager.services module with the resulting application and 
cleans up the gradle sourceSet.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8182778
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8182778/webrev.00/

Chris


[10] Review request: JDK-8181738 Remove com.sun.tools.jdeps to jdk.packager

2017-06-15 Thread Chris Bensen
Kevin, Victor,

Please review this change following JDK-8179445 to remove the qualified exports 
of com.sun.tools.jdeps:
 
JIRA: https://bugs.openjdk.java.net/browse/JDK-JDK-8181738
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-JDK-8181738/webrev.00/

Chris


[9] Review request: 8179363 Errors in Redistributable Module List

2017-04-26 Thread Chris Bensen
Kevin, Victor,

Please review this change to fix the redistributable file list.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8179363
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8179363/webrev.00/

Chris


Re: javapackager - partially self-contained apps in JDK 9

2017-04-25 Thread Chris Bensen
The code that I included below will do what you want with modular JARs. I hope 
to get this as a feature of the Java Packager which would be called Pugins, but 
there’s only so much time, which is why I provided you with a portion of my 
prototype code.

Chris


> On Apr 25, 2017, at 12:11 PM, Alan Snyder <javali...@cbfiddle.com> wrote:
> 
> The whole point is not to include the connector JAR in the bundled app, so 
> that it can upgraded independently.
> 
> I tried setting -classpath using fx:jvmuserarg, the app crashed (exit 1) on 
> startup.
> 
> I really wonder why this case is not handled in some convenient way.
> 
> 
> 
> 
>> On Apr 25, 2017, at 11:32 AM, Chris Bensen <chris.ben...@oracle.com> wrote:
>> 
>> 
>>> On Apr 11, 2017, at 10:43 AM, Alan Snyder <javali...@cbfiddle.com> wrote:
>>> 
>>> I have run into a problem in moving my macOS apps from JDK 8 to 9. The 
>>> issue relates to using MySQL via JDBC.
>>> The connector class name is fixed. The class is loaded using 
>>> Class.forName(). However, there can be different versions
>>> of the connector in different JAR files, and the proper version might need 
>>> to be synced with the currently installed version
>>> of MySQL.
>>> 
>>> In JDK 8, I used the extension mechanism to load the MySQL connector JAR 
>>> rather than building this JAR into the bundled app.
>>> My thinking was that the connector might need to be updated in sync with 
>>> the database and I should not have to rebuild apps to do that.
>>> 
>>> In JDK 9, the extension mechanism is gone. I have not found any way to 
>>> achieve the equivalent effect. It seems that javapackager
>>> controls the setting of the CLASSPATH. I have not found an option that 
>>> would allow me to extend the CLASSPATH with a directory
>>> where the connector JAR could be found. Is there a way to do this?
>>> 
>>> Alan
>>> 
>> 
>> 
>> Are you including the connector JAR in the app image?
>> 
>> I think you could set the classpath if you us ant-javafx.jar:
>> 
>> 
>> 
>> but honestly I’ve never tried it with JDK 9.
>> 
>> A JDK 9 way of dynamically loading this would be to create a Layer. Here’s 
>> some semi working code you could use:
>> 
>> 
>>   public Plugin loadPlugin(String module, String classname) {
>>   Plugin result = null;
>>   Configuration cf = 
>> resolve(file.getAbsoluteFile().getParentFile().toPath(), name);
>>   ClassLoader scl = ClassLoader.getSystemClassLoader();
>>   Layer layer = Layer.boot().defineModulesWithOneLoader(cf, scl);
>>   ClassLoader cl = layer.findLoader(name);
>> 
>>   try {
>>   result = createPlugin(layer, name, classname);
>>   result.load();
>>   plugins.add(result);
>>   }
>>   catch (Exception e) {
>>   System.out.println("oh no!" + e.toString());
>>   }
>> 
>>   return result;
>>   }
>> 
>>   private static Configuration resolve(Path modulepath, String... roots) {
>>   ModuleFinder finder = ModuleFinder.of(modulepath);
>>   return Layer.boot()
>>   .configuration()
>>   .resolve(finder, ModuleFinder.of(), Set.of(roots));
>>   }
>> 
>>   private static Plugin createPlugin(Layer layer, String mn, String mc) 
>> throws Exception {
>>   ClassLoader loader = layer.findLoader(mn);
>>   Class c = loader.loadClass(mc);
>>   Plugin p = (Plugin)c.getConstructor().newInstance();
>>   return p;
>>   }
>> 
>> Chris
> 



Re: javapackager - partially self-contained apps in JDK 9

2017-04-25 Thread Chris Bensen

> On Apr 11, 2017, at 10:43 AM, Alan Snyder  wrote:
> 
> I have run into a problem in moving my macOS apps from JDK 8 to 9. The issue 
> relates to using MySQL via JDBC.
> The connector class name is fixed. The class is loaded using Class.forName(). 
> However, there can be different versions
> of the connector in different JAR files, and the proper version might need to 
> be synced with the currently installed version
> of MySQL.
> 
> In JDK 8, I used the extension mechanism to load the MySQL connector JAR 
> rather than building this JAR into the bundled app.
> My thinking was that the connector might need to be updated in sync with the 
> database and I should not have to rebuild apps to do that.
> 
> In JDK 9, the extension mechanism is gone. I have not found any way to 
> achieve the equivalent effect. It seems that javapackager
> controls the setting of the CLASSPATH. I have not found an option that would 
> allow me to extend the CLASSPATH with a directory
> where the connector JAR could be found. Is there a way to do this?
> 
>  Alan
> 


Are you including the connector JAR in the app image?

I think you could set the classpath if you us ant-javafx.jar:



but honestly I’ve never tried it with JDK 9.

A JDK 9 way of dynamically loading this would be to create a Layer. Here’s some 
semi working code you could use:


public Plugin loadPlugin(String module, String classname) {
Plugin result = null;
Configuration cf = 
resolve(file.getAbsoluteFile().getParentFile().toPath(), name);
ClassLoader scl = ClassLoader.getSystemClassLoader();
Layer layer = Layer.boot().defineModulesWithOneLoader(cf, scl);
ClassLoader cl = layer.findLoader(name);

try {
result = createPlugin(layer, name, classname);
result.load();
plugins.add(result);
}
catch (Exception e) {
System.out.println("oh no!" + e.toString());
}

return result;
}

private static Configuration resolve(Path modulepath, String... roots) {
ModuleFinder finder = ModuleFinder.of(modulepath);
return Layer.boot()
.configuration()
.resolve(finder, ModuleFinder.of(), Set.of(roots));
}

private static Plugin createPlugin(Layer layer, String mn, String mc) 
throws Exception {
ClassLoader loader = layer.findLoader(mn);
Class c = loader.loadClass(mc);
Plugin p = (Plugin)c.getConstructor().newInstance();
return p;
}

Chris

[10] Review request: 8176825 Unwanted comment in jdk.packager.services/src/main/java/module-info.java

2017-04-11 Thread Chris Bensen
Victor,

Please review this minor change to remove and unwanted comment.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8176825
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8176825/webrev.00/

Chris


[9] Review request: 8178413 Mark All Exported Java Packager APIs as Deprecated

2017-04-11 Thread Chris Bensen
Kevin, Victor, and Mandy,

Please review this change to deprecate all the existing non documented Java 
Packager API for JDK 9 and provide a new API for JDK 10.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8178413
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8178413/webrev.02/

Chris


[9] Review request: 8177451 javapackager -help prints help message of java -help

2017-03-24 Thread Chris Bensen
Kevin,

Please review this fix to the javapackager.exe launcher. My last change, I 
thought I had tested it thoroughly but I made a mistake where I put one of the 
quotes but I also noticed some other problems. So it’s now launching as a 
modular application as well. This time I’ve carefully tested it and we’re good.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8177451
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8177451/webrev.00/

Chris


[9] Review request: 8176582 javapackager.exe doesn't work from c:\program files

2017-03-14 Thread Chris Bensen
Kevin, Victor,

Please review this change to add quotes around path strings.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8176582
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8176582/webrev.01/

Chris


[9] Review request: 8150511 LSMinimumSystemVersion set incorrectly

2017-02-23 Thread Chris Bensen
Victor,

Please review this change to the minimum supported system version.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8150511
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8150511/webrev.00/

Chris


[8] Review request: 8174842 Uninitialized variable in PosixPlatform.cpp

2017-02-17 Thread Chris Bensen
Kevin,

Please review backport request:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8174842
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8174842/webrev.03/

Chris


Re: [8] Review request: 8173139 Packager update App Store runtime rules for libjfxwebkit.dylib

2017-02-15 Thread Chris Bensen
Accidentally send out the wrong bug number. Here’s the correct one:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8174806 
<https://bugs.openjdk.java.net/browse/JDK-8174806>
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8174806/webrev.00/ 
<http://cr.openjdk.java.net/~cbensen/JDK-8174806/webrev.00/>

Chris


> On Feb 15, 2017, at 9:46 AM, Chris Bensen <chris.ben...@oracle.com> wrote:
> 
> Kevin,
> 
> Please review this change to no longer strip libjfxwebkit.dylib after 8u152 
> from a packaged app.
> 
> JIRA: https://bugs.openjdk.java.net/browse/8173139
> Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8173139/webrev.00/
> 
> Chris



[8] Review request: 8173139 Packager update App Store runtime rules for libjfxwebkit.dylib

2017-02-15 Thread Chris Bensen
Kevin,

Please review this change to no longer strip libjfxwebkit.dylib after 8u152 
from a packaged app.

JIRA: https://bugs.openjdk.java.net/browse/8173139
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8173139/webrev.00/

Chris


[9] Review request: JDK-8174842 Uninitialized variable in PosixPlatform.cpp

2017-02-13 Thread Chris Bensen
Victor,

Please review the fix for initializing the uninitialized variable.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8174842 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8174842/webrev.00/ 


Chris

[9] Review request:

2017-02-08 Thread Chris Bensen
Kevin, Victor:

Updating the redistributable module list, changing the name to legacy/jre.list 
and adding support for comments in the jre.list file.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8174131 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8174131/webrev.00/ 


Chris

Re: [9] Review request: JDK-8147781: Javapackager installer needs to cleanup temporary folders

2017-02-06 Thread Chris Bensen
That’s a good point Stefan. I hadn’t noticed the -verbose.

Chris


> On Feb 6, 2017, at 4:31 PM, Stefan Fuchs  wrote:
> 
> Hi,
> 
> are you sure that there is a bug?
> 
> The verbose paramter is explicitly documented to leave temporary files 
> around, as a starting point for customization.
> 
> Quote from 
> https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html
> 
> Verbose mode includes the following actions:
> 
> .
> 
> A copy of the configuration files and resources used to create the self 
> contained package are saved to a temporary folder. You can use these files as 
> a starting point for customization
> 
> ...
> 
> 
> - Stefan
>> Chris,
>> 
>> Please review the changes about removing temporary files.
>> 
>> JIRA: https://bugs.openjdk.java.net/browse/JDK-8147781
>> Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8147781/webrev.00/
>> 
>> --Victor
>> 
>> 
> 



[9] Review request: 8173774 Update script and icon

2017-02-01 Thread Chris Bensen
Victor,

Please review these minor changes to the AppStore version number and icons for 
submitting to the Mac AppStore.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8173774
 Webrev: 
http://cr.openjdk.java.net/~cbensen/JDK-8173774/webrev.02/ 


Chris

[9] Review request: 8173661 Fix ALL-MODULE-PATH

2017-02-01 Thread Chris Bensen
Victor,

Please review this change to the addModules. ALL-MODULE-PATH now works with 
this change but it is subtle and we need to make sure it doesn’t break anything.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8173661 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8173661/webrev.00/ 


Chris

[9] Review request: 8173407 New Ensemble AppStore icon

2017-01-26 Thread Chris Bensen
Victor,

Please review this very minor change. Rename of the Ensemble illustrator file, 
along with an updated version that the AppStore should be happy with, and the 
new PNG.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8173407 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8173407/webrev.00/ 


Chris

[9] Review request: 8173225 codesign fails on symlinks

2017-01-23 Thread Chris Bensen
Victor,

Please review these changes to submit apps to the Mac App store.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8173225 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8173225/webrev.01/ 


Chris

[9] Review request:

2017-01-20 Thread Chris Bensen
Victor,

Please review this change to provide a warning with suggested work arounds when 
packaging on Windows 10 with Windows Defender enabled.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8172444 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8172444/webrev.01/ 


Chris

[9] Review request: 8171811 References to ant-javafx.jar

2017-01-19 Thread Chris Bensen
Victor,

Please review these string changes to remove ant-javafx.jar from the error 
messages where they shouldn’t be.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8171811 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8171811/webrev.00/ 


Chris

Re: CFV: New OpenJFX Committer: Ramesh Gangadhar

2017-01-18 Thread Chris Bensen
Correct:

Vote: YES


> On Jan 18, 2017, at 2:10 PM, Chris Bensen <chris.ben...@oracle.com> wrote:
> 
> Not: YES
> 
> 
>> On Jan 18, 2017, at 1:53 PM, Kevin Rushforth <kevin.rushfo...@oracle.com> 
>> wrote:
>> 
>> I hereby nominate Ramesh Gangadhar [1] to OpenJFX Committer.
>> 
>> Ramesh is a member of JavaFX SQE team at Oracle working on test development 
>> for the Java packager, who has contributed 20 changesets to OpenJFX, at 
>> least 8 of which [5] are significant.
>> 
>> Votes are due by February 1, 2017.
>> 
>> Only current OpenJFX Committers [2] 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 [3]. Nomination to a project 
>> Committer is described in [4].
>> 
>> Thanks,
>> 
>> -- Kevin
>> 
>> 
>> [1] http://openjdk.java.net/census#rgangadhar
>> 
>> [2] http://openjdk.java.net/census#openjfx
>> 
>> [3] http://openjdk.java.net/bylaws#lazy-consensus
>> 
>> [4] http://openjdk.java.net/projects#project-committer
>> 
>> [5]  List of significant changesets:
>> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0b702e5db31c
>> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0787febc9b94
>> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b80a8efca46c
>> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/9fe019fe7f5c
>> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/bf6ae1d345ce
>> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/be0c0e2d0d31
>> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b743144c5e11
>> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0181e5e6b9bb
>> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/a141695f4a7f
>> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/16542d3f79a9
>> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/78f45d216138
>> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/92b56a32ebd1
>> 
> 



Re: CFV: New OpenJFX Committer: Ramesh Gangadhar

2017-01-18 Thread Chris Bensen
Not: YES


> On Jan 18, 2017, at 1:53 PM, Kevin Rushforth  
> wrote:
> 
> I hereby nominate Ramesh Gangadhar [1] to OpenJFX Committer.
> 
> Ramesh is a member of JavaFX SQE team at Oracle working on test development 
> for the Java packager, who has contributed 20 changesets to OpenJFX, at least 
> 8 of which [5] are significant.
> 
> Votes are due by February 1, 2017.
> 
> Only current OpenJFX Committers [2] 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 [3]. Nomination to a project 
> Committer is described in [4].
> 
> Thanks,
> 
> -- Kevin
> 
> 
> [1] http://openjdk.java.net/census#rgangadhar
> 
> [2] http://openjdk.java.net/census#openjfx
> 
> [3] http://openjdk.java.net/bylaws#lazy-consensus
> 
> [4] http://openjdk.java.net/projects#project-committer
> 
> [5]  List of significant changesets:
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0b702e5db31c
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0787febc9b94
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b80a8efca46c
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/9fe019fe7f5c
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/bf6ae1d345ce
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/be0c0e2d0d31
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b743144c5e11
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0181e5e6b9bb
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/a141695f4a7f
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/16542d3f79a9
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/78f45d216138
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/92b56a32ebd1
> 



[9] Review request: 8172985 Executable files in repo after JDK-8172925

2017-01-18 Thread Chris Bensen
Kevin,

Please review my fixing my mistake.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8172985 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8172985/webrev.00/ 


Chris

[9] Review request: 8172925 Mac App Store

2017-01-17 Thread Chris Bensen
Victor,

Please review the first pass at the Mac App Store changes.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8172925 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8172925/webrev.00/ 


Thanks,
Chris

[9] Review request: 8171979 Missing/Renamed Modules in Redistributable list

2017-01-11 Thread Chris Bensen
Victor,

Please review this change to the redistributable module list.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8171979
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8171979/webrev.00/

Thanks,
Chris


Result: New OpenJFX Committer: Victor Drozdov

2017-01-04 Thread Chris Bensen
Voting for Victor Drozdov [1] to OpenJFX Committer [2] is now closed.

Yes: 7
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient to 
approve the nomination.

Chris

[1] http://openjdk.java.net/census#vdrozdov 

[2] 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2016-December/020082.html 


[9] Review request: JDK-8168306 Iconswap program used by the packager is flagged as malware by Windows Defender

2016-12-21 Thread Chris Bensen
Kevin, Victor,

Please review this change to do away with the tools iconswap.exe and 
versioninfoswap.exe by folding them into javapackager.exe to avoid the problems 
of these being copied as a resource out of the Java Packager into executing 
from the temporary directory.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8168306 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8168306/webrev.01/ 


Chris

[9] Review request: JDK-8171352 javapackager throws "Exception: jdk.tools.jlink.plugin.PluginException: java.lang.IllegalArgumentException: No modules to add" when bundled with NormalJar

2016-12-16 Thread Chris Bensen
Kevin,

Please review this minor change to build.gradle as a follow on to JDK-8170198. 
The location of the redistributable.list was incorrect and my testing didn’t 
catch it.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8171352 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8171352/webrev.00/ 


Chris

[9] Review request: JDK-8170198 Static Redistributable Module List

2016-12-14 Thread Chris Bensen
Kevin,

Please review this change to no longer generate the Java Packager’s 
redistributable module list instead use a static list since the 
programmatically generated list uses the boot JDK’s list of modules and that 
can vary between builds.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8170198 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8170198/webrev.00/ 


Chris

Re: CFV: New OpenJFX Committer: Victor Drozdov

2016-12-14 Thread Chris Bensen
Vote: yes

> On Dec 13, 2016, at 4:21 PM, Chris Bensen <chris.ben...@oracle.com> wrote:
> 
> I hereby nominate Victor Drozdov [1] to OpenJFX Committer.
> 
> Victor is a member of Java Deployment team at Oracle working on the Java 
> Packager tool, who has contributed 11 changesets [5] to OpenJFX, at least 8 
> of which are significant.
> 
> Votes are due by January 4, 2017.
> 
> Only current OpenJFX Committers [2] 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 [3]. Nomination to a project 
> Committer is described in [4].
> 
> Thanks,
> 
> [1] http://openjdk.java.net/census#vdrozdov 
> <http://openjdk.java.net/census#vdrozdov>
> 
> [2] http://openjdk.java.net/census#openjfx 
> <http://openjdk.java.net/census#openjfx>
> 
> [3] http://openjdk.java.net/bylaws#lazy-consensus 
> <http://openjdk.java.net/bylaws#lazy-consensus>
> 
> [4] http://openjdk.java.net/projects#project-committer 
> <http://openjdk.java.net/projects#project-committer>
> 
> [5] List of changesets:
> 
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/81268b9c41f6 
> <http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/81268b9c41f6>
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/4272317a42ad 
> <http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/4272317a42ad>
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/3ca13b05a699 
> <http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/3ca13b05a699>
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/6dfb3daf92cf 
> <http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/6dfb3daf92cf>
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/2b649093eb50 
> <http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/2b649093eb50>
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/2538169ab7bb 
> <http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/2538169ab7bb>
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/a6fafaa51082 
> <http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/a6fafaa51082>
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/ac334db87ed6 
> <http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/ac334db87ed6>
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/12e6cb1e78af 
> <http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/12e6cb1e78af>
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/32cc74546935 
> <http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/32cc74546935>
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/6b55a303625d 
> <http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/6b55a303625d>



Re: [9] Review request: JDK-8169443 Deprecate Java Packager Blob Signing

2016-12-13 Thread Chris Bensen
The “new” was introduced for some reason in JDK 1.8 documentation but this has 
been there since JDK 1.0 documentation which I can’t find but it’s also there 
since JDK 2.0 [1].

The deployment guide will be updated.

Chris

[1] http://docs.oracle.com/javafx/2/deployment/javafx_ant_task_reference001.htm 



> On Dec 13, 2016, at 3:52 PM, Stefan Fuchs  wrote:
> 
> Well, in Java 8  is part of the javafx_ant_task reference [1]
> and advertised as being the new and more efficient way to sign jars [2]
> 
> Anyway, perhaps the deprecation message for  could be enhanced to 
> point to https://ant.apache.org/manual/Tasks/signjar.html as the recommended 
> way to sign jars.
> The Deployment Guide should be updated as well.
> 
> - Stefan
> 
> 
> [1] 
> http://docs.oracle.com/javase/8/docs/technotes/guides/deploy/javafx_ant_task_reference.html#CIADDAEE
> [2] 
> http://docs.oracle.com/javase/8/docs/technotes/guides/deploy/packaging.html#BABJGFBH
> 
> 
> 
> David DeHaven wrote:
>> This is only signing via the  mechanism, which was never fully 
>> supported or part of any standard. To sign webstart applications (even FX 
>> apps) just use jarsigner or the associated ant signjar task.
>> 
>> -DrD-
>> 
>> [1] https://ant.apache.org/manual/Tasks/signjar.html
>> 
>>> On Dec 13, 2016, at 11:02 AM, Stefan Fuchs  wrote:
>>> 
>>> Hi Chris,
>>> 
>>> well I think reason number 1 is not correct. The definition of self signed 
>>> depends on who created the signing key. If you created it yourself, it is a 
>>> self signed jar and will rightfully be blocked.
>>> If you however obtained the signing key from a Certification Authority, 
>>> that java accepts, it is not a self signed jar and will not be blocked.
>>> This is a perfectly valid usecase for fxsign jar.
>>> 
>>> For the 2nd reason: I don't think many users will go modular for Webstart 
>>> Applications. Normally you simply pack all your classes in a single big 
>>> jar-file (and perhaps a second, if you use a preloader).
>>> This avoids various network round trips, when the application starts and 
>>> makes deployment much easier.
>>> 
>>> 
>>> Stefan
>>> 
 Hi Stefan,
 
 Yes, it is being deprecated. It will continue to function as it has. Two 
 main reasons for the deprecation are:
 
 1. Self signed jars are blocked and sign as blob is a self signed jars.
 
 2. There will be a replacement for modules that will be better.
 
 Chris
 
 
> On Dec 12, 2016, at 11:56 PM, Stefan Fuchs  wrote:
> 
> Hi,
> 
> so blog signing as deprecated.
> 
> What are the reasons for deprecating blog signing? Are there alternatives?
> How do I sign a webstart application?
> 
> Stefan
> 
>> David,
>> 
>> Please review these changes to deprecate the blob signing from the Java 
>> Packager.
>> 
>> JIRA: https://bugs.openjdk.java.net/browse/JDK-8169443 
>> 
>> Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8169443/webrev.00/ 
>> 
>> 
>> Chris
>> 
> 



CFV: New OpenJFX Committer: Victor Drozdov

2016-12-13 Thread Chris Bensen
I hereby nominate Victor Drozdov [1] to OpenJFX Committer.

Victor is a member of Java Deployment team at Oracle working on the Java 
Packager tool, who has contributed 11 changesets [5] to OpenJFX, at least 8 of 
which are significant.

Votes are due by January 4, 2017.

Only current OpenJFX Committers [2] 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 [3]. Nomination to a project 
Committer is described in [4].

Thanks,

[1] http://openjdk.java.net/census#vdrozdov 


[2] http://openjdk.java.net/census#openjfx 


[3] http://openjdk.java.net/bylaws#lazy-consensus 


[4] http://openjdk.java.net/projects#project-committer 


[5] List of changesets:

http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/81268b9c41f6 

http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/4272317a42ad 

http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/3ca13b05a699 

http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/6dfb3daf92cf 

http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/2b649093eb50 

http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/2538169ab7bb 

http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/a6fafaa51082 

http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/ac334db87ed6 

http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/12e6cb1e78af 

http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/32cc74546935 

http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/6b55a303625d 


Re: [9] Review request: JDK-8169443 Deprecate Java Packager Blob Signing

2016-12-13 Thread Chris Bensen
Hi Stefan,

Yes, it is being deprecated. It will continue to function as it has. Two main 
reasons for the deprecation are:

1. Self signed jars are blocked and sign as blob is a self signed jars.

2. There will be a replacement for modules that will be better.

Chris


> On Dec 12, 2016, at 11:56 PM, Stefan Fuchs  wrote:
> 
> Hi,
> 
> so blog signing as deprecated.
> 
> What are the reasons for deprecating blog signing? Are there alternatives?
> How do I sign a webstart application?
> 
> Stefan
> 
>> David,
>> 
>> Please review these changes to deprecate the blob signing from the Java 
>> Packager.
>> 
>> JIRA: https://bugs.openjdk.java.net/browse/JDK-8169443 
>> 
>> Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8169443/webrev.00/ 
>> 
>> 
>> Chris
> 



[9] Review request: JDK-8169443 Deprecate Java Packager Blob Signing

2016-12-12 Thread Chris Bensen
David,

Please review these changes to deprecate the blob signing from the Java 
Packager.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8169443 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8169443/webrev.00/ 


Chris

[9] Review request: JDK-8170883 Add Class Path to Examples

2016-12-08 Thread Chris Bensen
Kevin, Victor,

Please review changes to the Java Packager examples and a new example mixing 
modular jars and non modular jars.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8170883 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8170883/webrev.00/ 


Chris

[9] Review request: JDK-8168407 javapackager throws "java.lang.ClassNotFoundException: testapp.util.Util" when bundle is built through ANT for unnamed module depending on named module scenario

2016-12-08 Thread Chris Bensen
Kevin,

Please review this change to allow a non modular jar main app to use and bundle 
modular jars into the runtime image.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8168407 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8168407/webrev.00/ 


Chris

[9] Review request: JDK-8170609: Show Error When Mac AppStore Certificate Expired

2016-12-01 Thread Chris Bensen
Victor,

Please review the changes to show an error when the MacApp Store certificate 
has expired.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8170609
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8170609/webrev.00/

Chris

[9] Review request: JDK-8170295 fx:jvmarg is not set

2016-11-28 Thread Chris Bensen
Victor,

Please review this change to fix setting of jvmarg options:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8170295
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8170295/webrev.00/

Chris


[9] Review request: JDK-8170122 Packager Tests

2016-11-28 Thread Chris Bensen
Victor,

Please review these Java Packager examples:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8170122
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8170122/webrev.01/

Chris


[9] Review request: 8170122: Packager Tests

2016-11-22 Thread Chris Bensen
Kevin,

Adding Java Packager examples/tests.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8170122
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8170122/webrev.00/

Chris


[9] Review request: JDK-8167508 ant-javafx.jar and jdk.packager runtime version check

2016-11-16 Thread Chris Bensen
Kevin,

Please review this change to have ant-javafx.jar check the version of Java that 
is running it and match the version it was intended to run with by comparing 
against a version string that is stored in the jar file.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8167508
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8167508/webrev.01/

Chris

Re: [9] Review request: DK-8169417: JavaFX to include jake-compatible versions of module-info.java with import bundles

2016-11-08 Thread Chris Bensen
+1 I did a quick test on Mac and it worked for me.

Chris


> On Nov 8, 2016, at 4:11 PM, Kevin Rushforth  
> wrote:
> 
> Hi,
> 
> Please review the following fix to include jake-compatible versions of 
> module-info.java with our input bundles:
> 
> https://bugs.openjdk.java.net/browse/JDK-8169417
> http://cr.openjdk.java.net/~kcr/8169417/webrev.00/
> 
> These new files end up in a new "modules_src_jake" subdirectory of 
> modular-sdk, and are zipped up delivered to the JDK build as 
> javafx-exports.zip along with the existing directories. The existing jdk9 
> build will not be affected. The jisgaw/jake build will take the 
> modules_src_jake files in preference to modules_src.
> 
> NOTE: for the files that have a jake-equivalent, we will need to keep them in 
> sync going forward for as long as we need both.
> 
> -- Kevin
> 



Re: javapacker's iconswap flagged as malware

2016-10-18 Thread Chris Bensen
Hi Scott,

I’m not actively running Windows 10 and last time I did run the Java Packager 
under Windows 10 it worked just fine so this is new behavior within I’d say the 
last 6 months. Feel free to file a bug, but I’m not sure there’s anything that 
can be done from the JDK side.

Thanks,
Chris


> On Oct 18, 2016, at 1:16 PM, Scott Palmer  wrote:
> 
> Just tried to run a build on Windows 10 with 8u112 and got this:
> 
> Exception: java.io.IOException: Cannot run program
> "C:\Users\spalmer\AppData\Local\Temp\iconswap2930071229376508731.exe":
> CreateProcess error=225, Operation did not complete successfully because
> the file contains a virus or potentially unwanted software
> 
> Windows Defender quarantined the file. It listed it and the launcher .exe
> for my application as threats:
> Trojan:Win32/Detplock
> Trojan:Win32/Repjexi
> 
> 
> I had to explicitly go into Windows Defender and pick "Allow Item" to get
> the build to succeed.
> 
> After that subsequent scans of the created launcher .exe with Windows
> Defender came back clean.
> 
> Are you aware of this issue?  I didn't see anything in Jira but I can't
> recall if I ever needed to bypass this check before.
> 
> Regards,
> 
> Scott



[9] Review request: JDK-8167973 Absolute path for module-path is not working when trying to execute javapackager from other drive in CLI

2016-10-18 Thread Chris Bensen
Kevin,

Please review this change to fix the path separate for Windows.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8167973
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8167973/webrev.00/

Chris


[9] Review request: JDK-8167496 Packager Cleanup

2016-10-11 Thread Chris Bensen
Kevin,

Just some cleanup.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8167496 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8167496/webrev.00/ 


Chris

[9] Review request: JDK-8166661 Remove "-outfile" as compulsary when bundling modules in javapackager

2016-10-07 Thread Chris Bensen
Kevin,

Please review the following change to remove the required argument -outfile.

JIRA: https://bugs.openjdk.java.net/browse/JDK-811
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-811/webrev.00/ 


Chris

Re: [9] Review Request: 8165414 javapackager throws NullPointerException in Windows Operating System for CLI

2016-10-06 Thread Chris Bensen
Kevin, did you see this one too?

Chris


> On Oct 5, 2016, at 8:11 AM, Chris Bensen <chris.ben...@oracle.com> wrote:
> 
> Kevin,
> 
> This resolves the NullPointerExceptions when packaging on Windows.
> 
> JIRA: https://bugs.openjdk.java.net/browse/JDK-8165414 
> <https://bugs.openjdk.java.net/browse/JDK-8165414>
> Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8165414/webrev.00/ 
> <http://cr.openjdk.java.net/~cbensen/JDK-8165414/webrev.00/>
> 
> Chris



[9] Review Request: 8166881 .cfg Configuration file contains hard coded values of path

2016-10-05 Thread Chris Bensen
Kevin,

Fix so the config file entry of the jar file is not a hard coded path.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8166881 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8166881/webrev.00/ 


Chris

[9] Review Request: 8165414 javapackager throws NullPointerException in Windows Operating System for CLI

2016-10-05 Thread Chris Bensen
Kevin,

This resolves the NullPointerExceptions when packaging on Windows.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8165414 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8165414/webrev.00/ 


Chris

[9] Review Request:

2016-09-16 Thread Chris Bensen
Kevin,

Add modules and limit modules are broken in some situations.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8166172 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8166172/webrev.00/ 


Chris

[9] Review Request: 8165059 Many jdk.packager properties files are missing from javafxsdk.tbom

2016-09-13 Thread Chris Bensen
Kevin,

Files for translation.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8165059
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8165059/webrev.00/

Chris


[9] Review Request: 8165882 Java Packager Cleanup

2016-09-13 Thread Chris Bensen
Kevin,

Just some minor cleanup.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8165882
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8165882/webrev.00/

Chris


[9] Review Request: 8165548 javapackager -help shows --modulepath not --module-path

2016-09-06 Thread Chris Bensen
Kevin,

Please review this simple string change.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8165548
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8165548/webrev.00/

Chris


[9] Review Request:

2016-09-01 Thread Chris Bensen
Kevin,

Please review this change to fix the .properties files.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8165057
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8165057/webrev.00/

Chris


[9] Review Request: 8163076 javapackager bundling fails due to issue in JAVA-API

2016-08-31 Thread Chris Bensen
Kevin,

Please review this change to fix invoking the Java Packager through the Java 
Packager API.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8163076
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8163076/webrev.00/

Chris

[9] Review Request: 8164248 [packager] New Modular Arguments to be made public for Packager API

2016-08-25 Thread Chris Bensen
Kevin,

Please review the change to make all the modular arguments part of the Java 
Packager public API.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8164248
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8164248/webrev.00/

Thanks,
Chris

[9] Review Request: 8155956 Java Packager runtime argument

2016-08-24 Thread Chris Bensen
Kevin,

Please review change for Java Packager runtime argument and a few other minor 
changes.

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8155956/webrev.00/
JIRA: https://bugs.openjdk.java.net/browse/JDK-8155956

Chris

Re: CFV: New OpenJFX Committer: Andrey Rusakov

2016-07-25 Thread Chris Bensen
Vote: yes

Chris


> On Jul 23, 2016, at 7:42 AM, Kevin Rushforth  
> wrote:
> 
> I hereby nominate Andrey Rusakov [1] to OpenJFX Committer.
> 
> Andrey is a member of JavaFX SQE team at Oracle working on test development, 
> who has contributed 19 changesets [5] to OpenJFX, at least 8 of which are 
> significant.
> 
> Votes are due by August 6, 2016.
> 
> Only current OpenJFX Committers [2] 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 [3]. Nomination to a project 
> Committer is described in [4].
> 
> Thanks,
> 
> -- Kevin
> 
> [1] http://openjdk.java.net/census#arusakov
> 
> [2] http://openjdk.java.net/census#openjfx
> 
> [3] http://openjdk.java.net/bylaws#lazy-consensus
> 
> [4] http://openjdk.java.net/projects#project-committer
> 
> [5] List of changesets:
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/a1e73dd4613e
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/7cce7ed57d89
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/34e657660c5c
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0e78b9e0f50e
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/d356db6612c7
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/1be0ce8c6667
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/adbed89b4b79
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/30fbc7690076
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b6bd30234e94
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/9b0f70918dc4
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/38c836fde6ab
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/bee64c78137a
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/1e1aea3def0f
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/c20f5594ed04
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/f34e58cb89ff
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/558c27a5d330
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/8ab04be9195b
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/f741badededf
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/2e6d6f449f08
> 



[9] Review Request: 8149975: [packager] Programmatically Determine JDK or JRE Modules

2016-07-05 Thread Chris Bensen
Hi David,

Please review this change for the Java Packager to programmatically get a list 
of the modules that are to be redistributable. This was waiting on 
https://bugs.openjdk.java.net/browse/JDK-8155955 
 and 
https://bugs.openjdk.java.net/browse/JDK-8160005 
 which have now fixed, but is 
still waiting on https://bugs.openjdk.java.net/browse/JDK-8158410 
 but I thought I’d get the 
review complete in the meantime. Let me know if the build.gradle changes are to 
your liking.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8149975 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8149975/webrev.01/ 


Thanks,
Chris

Review Request: 8146582 Ant Support for modular arguments

2016-06-22 Thread Chris Bensen
Hi Kevin,

This change adds Ant support for the modular arguments and changes the CLI 
arguments to match the new proposed GNU-style arguments.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8146582
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8146582/webrev.00/

Thanks,
Chris

Review Request: 8154895 Revisit javapackager module path related options

2016-06-07 Thread Chris Bensen
Hi Kevin,

This change aligns the CLI of the Java Packager with the rest of the Java 
toolchain (-modulepath, -addmods, -limitmods and -m). Developers can continue 
to use the old style -srcfiles, -appClass and -BmainJar= CLI 
arguments to bundle non-modular applications.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8154895
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8154895/webrev.01/

Thanks,
Chris

Request Review: [9]: [packager] Refactor Java Packager

2016-04-27 Thread Chris Bensen
Kevin,

Please review this refactoring change. This is the FX side of JDK-8150990 where 
the parts of the jdk.packager module that depend on jlink are refactored and 
moved to the jdk.jlink module.


review: http://cr.openjdk.java.net/~cbensen/JDK-8154898/webrev.02/ 

JIRA: https://bugs.openjdk.java.net/browse/JDK-8154898

Thanks,
Chris

Re: [9]: : [packager] Module Path Packager Arguments

2016-04-12 Thread Chris Bensen
New webrev:

http://cr.openjdk.java.net/~cbensen/JDK-8150991/webrev.03/ 
<http://cr.openjdk.java.net/~cbensen/JDK-8150991/webrev.03/>

Chris


> On Apr 11, 2016, at 4:17 PM, Chris Bensen <chris.ben...@oracle.com> wrote:
> 
> Kevin,
> 
> Please review. This adds new argument to Java Packager, the Minesweeper FX 
> Appstore App and cleans a lot of things up. My Packager sandbox will be in 
> sync with 9dev except for refactoring changes.
> 
> https://bugs.openjdk.java.net/browse/JDK-8150991 
> <https://bugs.openjdk.java.net/browse/JDK-8150991>
> http://cr.openjdk.java.net/~cbensen/JDK-8150991/webrev.02 
> <http://cr.openjdk.java.net/~cbensen/JDK-8150991/webrev.02>
> 
> Chris



[9]: : [packager] Module Path Packager Arguments

2016-04-11 Thread Chris Bensen
Kevin,

Please review. This adds new argument to Java Packager, the Minesweeper FX 
Appstore App and cleans a lot of things up. My Packager sandbox will be in sync 
with 9dev except for refactoring changes.

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

http://cr.openjdk.java.net/~cbensen/JDK-8150991/webrev.02 


Chris

[Jake Review]: [packager] Module Path Packager Arguments

2016-04-06 Thread Chris Bensen
Kevin,

Please review. This adds new argument to Java Packager and cleans a lot of 
things up. My Packager sandbox will be in sync except for refactoring changes.

https://bugs.openjdk.java.net/browse/JDK-8150991 
http://cr.openjdk.java.net/~cbensen/JDK-8150991/webrev.01
 

Chris

Jake Review: [packager] Fix packager for jlink API changes

2016-04-05 Thread Chris Bensen
Kevin,

Fixes for the Java Packager.

https://bugs.openjdk.java.net/browse/JDK-8153529
http://cr.openjdk.java.net/~cbensen/JDK-8153529/webrev.00/

Chris


Re: Request Review: 8150991 [packager] Module Path Packager Arguments

2016-03-04 Thread Chris Bensen
Wrong comment. What I meant to say is “small packager change to add new 
arguments for the module path”.

Chris


> On Mar 3, 2016, at 10:22 AM, Chris Bensen <chris.ben...@oracle.com> wrote:
> 
> Hi Kevin,
> 
> Small packager change to pass module path to to the call to JDEPS.
> 
> JIRA: https://bugs.openjdk.java.net/browse/JDK-8150991 
> <https://bugs.openjdk.java.net/browse/JDK-8148654>
> Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8150991/webrev.00/ 
> <http://cr.openjdk.java.net/~cbensen/JDK-8148654/webrev.00/>
> 
> Thanks,
> Chris



Request Review: 8150991 [packager] Module Path Packager Arguments

2016-03-03 Thread Chris Bensen
Hi Kevin,

Small packager change to pass module path to to the call to JDEPS.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8150991 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8150991/webrev.00/ 


Thanks,
Chris

Request Review: 8148654 [packager] Add support for module path when calling jdeps

2016-03-01 Thread Chris Bensen
Hi Kevin,

Small packager change to pass module path to to the call to JDEPS.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8148654
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8148654/webrev.00/

Thanks,
Chris


Review Request: 8148978 [packager] bootmodules.jimage was renamed to modules

2016-02-23 Thread Chris Bensen
Hi David,

Please review this change to take into account the recent change to JLINK to 
rename bootmodules.jimage to modules. There’s a bit more in this change as well 
to just get the packager CLI working in general.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8148978 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8148978/webrev.00 


Thanks,
Chris

Review Request: 8150294 [packager] Netbeans Packager Project

2016-02-19 Thread Chris Bensen
Hi Kevin,

Please review this change to add a Netbeans project for the Java Packager 
jdk.packager module:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8150294 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8150294/webrev.00 


Thanks,
Chris

Review Request: 8149966 [packager] JLINK API changes

2016-02-18 Thread Chris Bensen
Hi Kevin,

Please review this fix for the changes to the JLINK API that the packager uses:

JIRA: https://bugs.openjdk.java.net/browse/JDK-8149966
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8149966/webrev.00/

Thanks,
Chris

Re: javapackager

2016-02-04 Thread Chris Bensen

> On Feb 3, 2016, at 1:08 PM, Scott Palmer <swpal...@gmail.com> wrote:
> 
> 
>> On Feb 3, 2016, at 11:40 AM, Chris Bensen <chris.ben...@oracle.com> wrote:
>> 
>> On Feb 2, 2016, at 7:27 PM, Scott Palmer <swpal...@gmail.com> wrote:
>>> 
>>> Note that this is a RPM-based system, apt-get is not available, yum is.
>>> 
>>> yum install libX11
>> 
>> What is the Linux system you are running?
> 
> It is a version of CentOS.  (Created within my company with minor tweaks for 
> branding purposes.)

When submitting a bug, make sure the test case works on Oracle Linux or Ubuntu 
since those are the only “supported” version of Linux.

> 
> 
>>> 
>>> It seems to be that javapackager has made a mistake and is claiming to 
>>> depend on the 32-bit packages even though it really requires the 64-bit 
>>> packages.
>> 
>> That’s what it’s sounding like to me. Looking at the code for the RPM 
>> bundler there isn’t anything I can find offhand that would suggest this. 
>> Bundling with 32/64-bit is triggered off the JDK used. Note that you have to 
>> bundle the same bitness JRE as the JDK. It should fail if it isn’t but that 
>> isn’t the case yet and that isn’t your problem. It appears the RPM generated 
>> is 32-bit. Unless you are bundling a 32-bit JRE and the RPM bundler keys off 
>> the native libraries used. Can you check the launcher executable? I think 
>> it’d be:
>> 
>> $ file myserver-1.0-1.x86_64/app/myserver
> 
> I had to extract the launcher from the .rpm.  There is no version of it that 
> is sitting around in the output folder.
> 
> myserver: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically 
> linked (uses shared libs), for GNU/Linux 2.6.15, 
> BuildID[sha1]=0x7e6522a86eca91b45cfb4dfa5defbddac0b1294a, not stripped
> 
> 
> So the 64-bit launcher is bundled.
> 
> 
>> 
>> Can you file a minimum test case along with the Linux system used so we can 
>> prioritize with other bugs and find a solution?
> 
> I’ll try to put something together.  I’m still eager to find a workaround 
> that I can implement with 8u72.
> 
> 
> Scott
> 
> 
>> 
>> Chris
>> 
>> 
>>> Scott 
>>> 
>>> 
>>>> On Feb 2, 2016, at 7:03 PM, Chris Bensen <chris.ben...@oracle.com> wrote:
>>>> 
>>>> This list or the Deployment blog 
>>>> (https://blogs.oracle.com/talkingjavadeployment/) are the best places to 
>>>> get help with the javapackager.
>>>> 
>>>> Is your app built with the 64-bit or 32-bit packager? I noticed “x86_64” 
>>>> appended to the name. If it’s 32-bit you could try running:
>>>> 
>>>> sudo apt-get install libx11-6:i386
>>>> 
>>>> Chris
>>>> 
>>>> 
>>>>> On Feb 2, 2016, at 1:49 PM, Scott Palmer <swpal...@gmail.com> wrote:
>>>>> 
>>>>> What's the best place to go to get help with using the javapackager ?
>>>>> 
>>>>> I've read the docs, but things aren't working smoothly and it would be
>>>>> helpful if there were some known working examples to base things on.  I'm
>>>>> not finding any examples that use the -daemon or -BserviceHint=true
>>>>> options, for example.
>>>>> 
>>>>> I attempted to make a .rpm that installs a service/daemon but when I try 
>>>>> to
>>>>> install it, it fails claiming the following dependencies cannot be met:
>>>>> 
>>>>>libX11.so.6 is needed by myserver-1.0-1.x86_64
>>>>>libXext.so.6 is needed by myserver-1.0-1.x86_64
>>>>>libXi.so.6 is needed by myserver-1.0-1.x86_64
>>>>>libXrender.so.1 is needed by myserver-1.0-1.x86_64
>>>>>libXtst.so.6 is needed by myserver-1.0-1.x86_64
>>>>>libasound.so.2 is needed by myserver-1.0-1.x86_64
>>>>> 
>>>>> Considering the app already runs fine on this same system, I'm a bit
>>>>> confused that it is complaining of missing dependencies.
>>>>> 
>>>>> Scott
> 



Re: javapackager

2016-02-04 Thread Chris Bensen
There weren’t any noticeable changes for Linux. Besides maybe this one, which 
if you could file a bug with steps to reproduce that’d be great.

Chris


> On Feb 4, 2016, at 7:12 AM, Scott Palmer <swpal...@gmail.com> wrote:
> 
> I noticed that the JDK on my Linux VM was 8u40,  I updated to 8u72 and then 
> got the following:
> 
> Bundler RPM Bundle skipped because of a configuration problem: Specified 
> license file is missing.  
> Advice to fix: Make sure that "EULA.rtf" references a file in the app 
> resources, and that it is relative file reference.
> 
> I wasn't able to do anything to convince it that the license file was there. 
> I just omitted it for now.
> 
> Updating to 8u72 did not solve my .rpm dependency issues.
> 
> Scott
> 
> On Wed, Feb 3, 2016 at 4:08 PM, Scott Palmer <swpal...@gmail.com 
> <mailto:swpal...@gmail.com>> wrote:
> 
> > On Feb 3, 2016, at 11:40 AM, Chris Bensen <chris.ben...@oracle.com 
> > <mailto:chris.ben...@oracle.com>> wrote:
> >
> > On Feb 2, 2016, at 7:27 PM, Scott Palmer <swpal...@gmail.com 
> > <mailto:swpal...@gmail.com>> wrote:
> >>
> >> Note that this is a RPM-based system, apt-get is not available, yum is.
> >>
> >> yum install libX11
> >
> > What is the Linux system you are running?
> 
> It is a version of CentOS.  (Created within my company with minor tweaks for 
> branding purposes.)
> 
> 
> >>
> >> It seems to be that javapackager has made a mistake and is claiming to 
> >> depend on the 32-bit packages even though it really requires the 64-bit 
> >> packages.
> >
> > That’s what it’s sounding like to me. Looking at the code for the RPM 
> > bundler there isn’t anything I can find offhand that would suggest this. 
> > Bundling with 32/64-bit is triggered off the JDK used. Note that you have 
> > to bundle the same bitness JRE as the JDK. It should fail if it isn’t but 
> > that isn’t the case yet and that isn’t your problem. It appears the RPM 
> > generated is 32-bit. Unless you are bundling a 32-bit JRE and the RPM 
> > bundler keys off the native libraries used. Can you check the launcher 
> > executable? I think it’d be:
> >
> > $ file myserver-1.0-1.x86_64/app/myserver
> 
> I had to extract the launcher from the .rpm.  There is no version of it that 
> is sitting around in the output folder.
> 
> myserver: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically 
> linked (uses shared libs), for GNU/Linux 2.6.15, 
> BuildID[sha1]=0x7e6522a86eca91b45cfb4dfa5defbddac0b1294a, not stripped
> 
> 
> So the 64-bit launcher is bundled.
> 
> 
> >
> > Can you file a minimum test case along with the Linux system used so we can 
> > prioritize with other bugs and find a solution?
> 
> I’ll try to put something together.  I’m still eager to find a workaround 
> that I can implement with 8u72.
> 
> 
> Scott
> 
> 
> >
> > Chris
> >
> >
> >> Scott
> >>
> >>
> >>> On Feb 2, 2016, at 7:03 PM, Chris Bensen <chris.ben...@oracle.com 
> >>> <mailto:chris.ben...@oracle.com>> wrote:
> >>>
> >>> This list or the Deployment blog 
> >>> (https://blogs.oracle.com/talkingjavadeployment/ 
> >>> <https://blogs.oracle.com/talkingjavadeployment/>) are the best places to 
> >>> get help with the javapackager.
> >>>
> >>> Is your app built with the 64-bit or 32-bit packager? I noticed “x86_64” 
> >>> appended to the name. If it’s 32-bit you could try running:
> >>>
> >>> sudo apt-get install libx11-6:i386
> >>>
> >>> Chris
> >>>
> >>>
> >>>> On Feb 2, 2016, at 1:49 PM, Scott Palmer <swpal...@gmail.com 
> >>>> <mailto:swpal...@gmail.com>> wrote:
> >>>>
> >>>> What's the best place to go to get help with using the javapackager ?
> >>>>
> >>>> I've read the docs, but things aren't working smoothly and it would be
> >>>> helpful if there were some known working examples to base things on.  I'm
> >>>> not finding any examples that use the -daemon or -BserviceHint=true
> >>>> options, for example.
> >>>>
> >>>> I attempted to make a .rpm that installs a service/daemon but when I try 
> >>>> to
> >>>> install it, it fails claiming the following dependencies cannot be met:
> >>>>
> >>>> libX11.so.6 is needed by myserver-1.0-1.x86_64
> >>>> libXext.so.6 is needed by myserver-1.0-1.x86_64
> >>>> libXi.so.6 is needed by myserver-1.0-1.x86_64
> >>>> libXrender.so.1 is needed by myserver-1.0-1.x86_64
> >>>> libXtst.so.6 is needed by myserver-1.0-1.x86_64
> >>>> libasound.so.2 is needed by myserver-1.0-1.x86_64
> >>>>
> >>>> Considering the app already runs fine on this same system, I'm a bit
> >>>> confused that it is complaining of missing dependencies.
> >>>>
> >>>> Scott
> 
> 



Re: javapackager

2016-02-03 Thread Chris Bensen
On Feb 2, 2016, at 7:27 PM, Scott Palmer <swpal...@gmail.com> wrote:
> 
> Note that this is a RPM-based system, apt-get is not available, yum is.
> 
> yum install libX11

What is the Linux system you are running?

> …
> Package libX11-1.6.0-2.1.el7.x86_64 already installed and latest version
> 
> I get a similar message for the other dependencies.
> 
> Examining the .rpm file I can see that the bundled runtime contains a 
> lib/amd64 folder, so I’m pretty sure everything it did was 64-bit.
> 
> If I run:
> 
> yum install libX11.so.6
> 
> it wants to install the i686 architecture.  
> 
> So I went ahead an used yum to install the dependencies that way, but it 
> failed on the last one (of course):
> $ sudo yum install libasound.so.2
> Resolving Dependencies
> --> Running transaction check
> ---> Package alsa-lib.i686 0:1.0.28-2.el7 will be installed
> --> Finished Dependency Resolution
> Error:  Multilib version problems found.
> …
>   ...you can also use --setopt=protected_multilib=false to remove
>   this checking, however this is almost never the correct thing to
>   do as something else is very likely to go wrong (often causing
>   much more problems).
> 
>   Protected multilib versions: alsa-lib-1.0.28-2.el7.i686 != 
> alsa-lib-1.0.27.2-3.el7.x86_64
> 
> 
> It seems to be that javapackager has made a mistake and is claiming to depend 
> on the 32-bit packages even though it really requires the 64-bit packages.

That’s what it’s sounding like to me. Looking at the code for the RPM bundler 
there isn’t anything I can find offhand that would suggest this. Bundling with 
32/64-bit is triggered off the JDK used. Note that you have to bundle the same 
bitness JRE as the JDK. It should fail if it isn’t but that isn’t the case yet 
and that isn’t your problem. It appears the RPM generated is 32-bit. Unless you 
are bundling a 32-bit JRE and the RPM bundler keys off the native libraries 
used. Can you check the launcher executable? I think it’d be:

$ file myserver-1.0-1.x86_64/app/myserver

Can you file a minimum test case along with the Linux system used so we can 
prioritize with other bugs and find a solution?

Chris


> Scott 
> 
> 
>> On Feb 2, 2016, at 7:03 PM, Chris Bensen <chris.ben...@oracle.com> wrote:
>> 
>> This list or the Deployment blog 
>> (https://blogs.oracle.com/talkingjavadeployment/) are the best places to get 
>> help with the javapackager.
>> 
>> Is your app built with the 64-bit or 32-bit packager? I noticed “x86_64” 
>> appended to the name. If it’s 32-bit you could try running:
>> 
>> sudo apt-get install libx11-6:i386
>> 
>> Chris
>> 
>> 
>>> On Feb 2, 2016, at 1:49 PM, Scott Palmer <swpal...@gmail.com> wrote:
>>> 
>>> What's the best place to go to get help with using the javapackager ?
>>> 
>>> I've read the docs, but things aren't working smoothly and it would be
>>> helpful if there were some known working examples to base things on.  I'm
>>> not finding any examples that use the -daemon or -BserviceHint=true
>>> options, for example.
>>> 
>>> I attempted to make a .rpm that installs a service/daemon but when I try to
>>> install it, it fails claiming the following dependencies cannot be met:
>>> 
>>>  libX11.so.6 is needed by myserver-1.0-1.x86_64
>>>  libXext.so.6 is needed by myserver-1.0-1.x86_64
>>>  libXi.so.6 is needed by myserver-1.0-1.x86_64
>>>  libXrender.so.1 is needed by myserver-1.0-1.x86_64
>>>  libXtst.so.6 is needed by myserver-1.0-1.x86_64
>>>  libasound.so.2 is needed by myserver-1.0-1.x86_64
>>> 
>>> Considering the app already runs fine on this same system, I'm a bit
>>> confused that it is complaining of missing dependencies.
>>> 
>>> Scott
>> 
> 



Re: javapackager

2016-02-02 Thread Chris Bensen
This list or the Deployment blog 
(https://blogs.oracle.com/talkingjavadeployment/) are the best places to get 
help with the javapackager.

Is your app built with the 64-bit or 32-bit packager? I noticed “x86_64” 
appended to the name. If it’s 32-bit you could try running:

sudo apt-get install libx11-6:i386

Chris


> On Feb 2, 2016, at 1:49 PM, Scott Palmer  wrote:
> 
> What's the best place to go to get help with using the javapackager ?
> 
> I've read the docs, but things aren't working smoothly and it would be
> helpful if there were some known working examples to base things on.  I'm
> not finding any examples that use the -daemon or -BserviceHint=true
> options, for example.
> 
> I attempted to make a .rpm that installs a service/daemon but when I try to
> install it, it fails claiming the following dependencies cannot be met:
> 
>libX11.so.6 is needed by myserver-1.0-1.x86_64
>libXext.so.6 is needed by myserver-1.0-1.x86_64
>libXi.so.6 is needed by myserver-1.0-1.x86_64
>libXrender.so.1 is needed by myserver-1.0-1.x86_64
>libXtst.so.6 is needed by myserver-1.0-1.x86_64
>libasound.so.2 is needed by myserver-1.0-1.x86_64
> 
> Considering the app already runs fine on this same system, I'm a bit
> confused that it is complaining of missing dependencies.
> 
> Scott



Re: [9] 8147492: [packager] javapackager.exe support for unicode

2016-01-22 Thread Chris Bensen
Kevin,

Just realized I forgot to add your email address to this.

Thanks,
Chris


> On Jan 21, 2016, at 8:47 AM, Chris Bensen <chris.ben...@oracle.com> wrote:
> 
> Kevin,
> 
> Please review the following fix
> 
> https://bugs.openjdk.java.net/browse/JDK-8147492
> http://cr.openjdk.java.net/~cbensen/JDK-8147492/webrev.00/
> 
> Thanks,
> Chris



[9] 8147492: [packager] javapackager.exe support for unicode

2016-01-21 Thread Chris Bensen
Kevin,

Please review the following fix

https://bugs.openjdk.java.net/browse/JDK-8147492
http://cr.openjdk.java.net/~cbensen/JDK-8147492/webrev.00/

Thanks,
Chris


[9] Review request for 8146169: Javapackager displays version as 8.0 instead of 9.0 for JDK9

2016-01-15 Thread Chris Bensen
Kevin,

Please review the following fix

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

http://cr.openjdk.java.net/~cbensen/JDK-8146169/webrev.00/ 


Thanks,
Chris

Re: [8u-dev] Review request: 8143314: Runtime not respected with INI-configuration while creating native bundle

2015-11-19 Thread Chris Bensen
+1, but then again, I’m not Danno


> On Nov 19, 2015, at 6:14 AM, Dmitry Cherepanov  
> wrote:
> 
> Chris, Danno,
> 
> Please review the following fix:
> 
> https://bugs.openjdk.java.net/browse/JDK-8143314
> http://cr.openjdk.java.net/~dcherepanov/8143314/webrev.0/
> 
> Dmitry
> 



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

2015-11-17 Thread Chris Bensen
There have been cases where Apple received the updated delivery and didn’t test 
the updated bits or sent the old rejection letter for some reason. I’m not 
exactly sure what it took and I’m not 100% sure this is the case but it 
required Apple to examine the new upload.

I have an app that I’m about to go through the AppStore process. I will publish 
my findings.

Chris


> On Nov 17, 2015, at 9:31 AM, Kevin Rushforth  
> wrote:
> 
> [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"

2015-11-17 Thread Chris Bensen
The change is only for the Mac App Store. You can easily look at the changeset 
associated with JDK-8138650 to verify this:

http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/761213753af4 



This is the relevant code change:

+++ 
b/modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacAppStoreBundler.java
Fri Oct 02 15:33:14 2015 -0600 

@@ -290,13 +290,33 @@ 

 
I18N.getString("error.non-existent-runtime.advice"))); 

 } 
  
-if (new File(baseDir, 
"Contents/Home/lib/libjfxmedia_qtkit.dylib").exists() 

-|| new File(baseDir, 
"Contents/Home/jre/lib/libjfxmedia_qtkit.dylib").exists()) 

-{ 
+int majorVersion; 

+int updateVersion; 

+ 
+try { 

+majorVersion = 
Integer.parseInt(params.get(".runtime.version.major").toString()); 

+updateVersion = 
Integer.parseInt(params.get(".runtime.version.update").toString()); 

+} catch (Exception e) { 

+// assume the worst 

+majorVersion = 8; 

+updateVersion = 60; 

+} 
+ 
+// Quicktime 

+// before 8u40 it was all of media 

+// after 8u40 QTKit dependencies are isolated in it's own library 

+if (majorVersion == 8 && updateVersion >= 40) { 

 
rules.add(JreUtils.Rule.suffixNeg("/lib/libjfxmedia_qtkit.dylib")); 

 } else { 

 rules.add(JreUtils.Rule.suffixNeg("/lib/libjfxmedia.dylib")); 

 } 
+ 
+// webkit 

+// 8u60 webkit started using an API Apple didn't like 

+if (majorVersion == 8 && updateVersion >= 60) { 

+rules.add(JreUtils.Rule.suffixNeg("/lib/libjfxwebkit.dylib")); 

+} 
+ 
 return rules.toArray(new JreUtils.Rule[rules.size()]); 

 }

Chris


> On Nov 17, 2015, at 11:00 AM, Kevin Rushforth  
> wrote:
> 
> 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 

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

2015-11-11 Thread Chris Bensen
Hi Tom,

Yes, I remember our conversation. Danno’s right, there’s an open bug. I thought 
it was resolved at some point. Each Operating System acts differently making it 
a tough problem. I’ll add it to my (very long) todo list and get to it as soon 
as I can.

Thanks,
Chris


> On Nov 11, 2015, at 7:23 AM, Danno Ferrin  wrote:
> 
> 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
> 



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

2015-10-19 Thread Chris Bensen
+1

Chris


> On Oct 19, 2015, at 1:02 PM, Danno Ferrin  wrote:
> 
> 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 
> 


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

2015-10-13 Thread Chris Bensen
+1

> On Oct 12, 2015, at 11:50 AM, Danno Ferrin  wrote:
> 
> 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: Mac App Store Refusal because of QTKit API's

2015-09-30 Thread Chris Bensen
I’ll be doing the JavaOne Packager talk and will include any information I can 
on the subject of the App Store that’s relevant.

Chris


> On Sep 30, 2015, at 12:09 PM, Scott Selvia <ssel...@gmail.com> wrote:
> 
> I'll update the thread when I get a response from Apple on my latest 
> submission. I believe someone is doing an App Store talk or packager talk at 
> JavaOne. They can include the information in the thread
> 
> Sent from my iPhone
> 
>> On Sep 30, 2015, at 3:05 PM, Scott Selvia <ssel...@gmail.com> wrote:
>> 
>> Phil, 
>> 
>> Yes I've done that and I've re-submitted the app again
>> 
>> I agree that I should not be penalized by the JRE one would hope that Oracle 
>> and Apple worked out the JRE do's and don't when it was decided that Java 
>> applications can be posted to the OS X App Store.  However I don't think it 
>> will do much good for me to open Apple bugs.  Oracles stick is much bigger 
>> than mine!!!
>> 
>> Scott
>> 
>> Sent from my iPhone
>> 
>>> On Sep 30, 2015, at 2:54 PM, Phil Race <philip.r...@oracle.com> wrote:
>>> 
>>> It looks like there may be something to this :-
>>> 
>>> On mac fx in 8u60 is linking webkit against the system icu library to find 
>>> these symbols.
>>> 
>>> $ nm -a libjfxwebkit.dylib | grep ubrk_getRuleStatus
>>>   U _ubrk_getRuleStatus
>>> $ otool -L libjfxwebkit.dylib | grep icu
>>>  /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 
>>> 51.1.0)
>>> 
>>> webkit has as "undefined" a much longer list than what Apple complained 
>>> about
>>> so it is not clear if they regard the entire library as off-limits or just 
>>> some subset.
>>> 
>>> So I don't think this is anything to do with QtKit but is a webkit problem.
>>> Removing that dylib is the apparent workaround, assuming you don't need it.
>>> If the packager can't handle that for you I suppose you need to manually
>>> get rid of it out of your JDK directory before packaging.
>>> 
>>> -phil.
>>> 
>>>> On 09/30/2015 10:44 AM, Scott Selvia wrote:
>>>> Will do
>>>> 
>>>> It seems Apple is not distinguishing the difference of who is using the 
>>>> APIs.  Just like the jfx media qt dylib filtered out of the Java packager 
>>>> process when building a Mac store app. I guess at this point they feel the 
>>>> WebKit dylib falls into the category.
>>>> 
>>>> I had an apple issue with the embedded info.plist bundle ID that is part 
>>>> of the jre packaged with the Mac application package generated with the 
>>>> packager. I had to hack the jdk update 60 info.plist file and change the 
>>>> bundle ID with a hashcode suffix.  This I opened an apple bug for stating 
>>>> that embedded frameworks should not trigger a bundle collision ID error 
>>>> when uploading an application. I have not had any additional responses
>>>> 
>>>> I guess I'll add another bug for embedded frameworks (in this case the 
>>>> JRE) using deprecated APIs
>>>> 
>>>> Scott
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>> On Sep 30, 2015, at 12:45 PM, Donald Smith <donald.sm...@oracle.com> 
>>>>> wrote:
>>>>> 
>>>>> Please let us know what you hear back with Apple on this given the 
>>>>> information below we hope they will see this as an oversight.
>>>>> 
>>>>> - Don
>>>>> 
>>>>>> On 30/09/2015 12:28 PM, Phil Race wrote:
>>>>>> Yes, these look like ICU functions which so far as I know FX only
>>>>>> references from its *own* internal copy of webkit which in turn has a 
>>>>>> copy of ICU.
>>>>>> 
>>>>>> What is very odd is that Apple is essentially then objecting to 
>>>>>> referencing
>>>>>> functions that are internal to your app. ie referenced by your app and 
>>>>>> also
>>>>>> fulfilled by your app, whereas I assume the app store checking should be
>>>>>> against deprecated Apple APIs that you reference in your app and that
>>>>>> are fulfilled by OSX (or iOS).
>>>>>> 
>>>>>> So something seems wrong here.
>>>>>> 
>>>>>> -phil.
>>>>>> 
>>>>

Re: Mac App Store Refusal because of QTKit API's

2015-09-30 Thread Chris Bensen
Hi Scott,

Those APIs are for the text system ICU. I believe the App Store team may be in 
error. Perhaps they accidentally copied the wrong forbidden APIs when writing 
the message.

Thanks,
Chris


> On Sep 29, 2015, at 3:15 AM, Scott Selvia  wrote:
> 
> I’m using JDK 8 update 60 and I just received an email from Apple saying that 
> my application is using deprecated QTKit API’s.  I’ve reviewed Danno Ferrin’s 
> JavaOne session from last year; it says that Update 40’s 
> libjfxmedia_qtkit.dylib or Update 20’s libjfxmedia.dylib should be removed 
> and are by the packager.  I have this line in my packager output from the 
> packager, as you can see the libfxmedia.dylib is in my app and pkg.  Is this 
> an oversight by the packager and the libfxmedia.dylib should also be removed 
> from my packaged application?
> 
> The original message from ITunes Connect said that these API’s are 
> referenced, when I questioned Apple as to what code was referencing these 
> they said it was the JavaFX Media library.
> 
> ITunes Connect Responce:
> 
> 2.31
> 
> Your app incorrectly implements sandboxing, or it contains one or more 
> entitlements with invalid values. Please review the included entitlements and 
> sandboxing documentation and resolve this issues before resubmitting a new 
> binary.
> 
> ubrk_getRuleStatus
> ubrk_setUText
> ucnv_getCanonicalName
> ucnv_reset
> ucol_strcollIter
> 
> Dear developer,
> 
> We have discovered one or more issues with your recent delivery for 
> "Examine-IT Pro". To process your delivery, the following issues must be 
> corrected:
> 
> Deprecated API Usage - Apple no longer accepts submissions of apps that use 
> QuickTime or QTKit APIs.
> 
> Once these issues have been corrected, you can then redeliver the corrected 
> binary.
> 
> Regards,
> 
> The App Store team
> 
> 
> 
> Running [codesign, -s, 3rd Party Mac Developer Application: THUNDERCLOUD 
> RESOURCES, LLC (82Z9WT6K6N), --prefix, com.thundercloudresources.examineit., 
> -, --entitlements, 
> /var/folders/wd/0dvkql1x0yxc9911tp1tz57cgq/T/fxbundler8869305413596109692/macosx/Examine-IT
>  Pro.entitlements, 
> /var/folders/wd/0dvkql1x0yxc9911tp1tz57cgq/T/fxbundler8869305413596109692/images/image-2516465556090179709/Examine-IT
>  
> Pro.app/Contents/PlugIns/Java.runtime/Contents/Home/jre/lib/libjfxmedia.dylib]
> /var/folders/wd/0dvkql1x0yxc9911tp1tz57cgq/T/fxbundler8869305413596109692/images/image-2516465556090179709/Examine-IT
>  
> Pro.app/Contents/PlugIns/Java.runtime/Contents/Home/jre/lib/libjfxmedia.dylib:
>  signed Mach-O thin (x86_64) [com.thundercloudresources.examineit.libjfxmedia]



Re: Review Request: RT-39975 - AppCDS support for packager

2015-03-31 Thread Chris Bensen
Correct!


On Mar 31, 2015, at 4:41 AM, Mike Hearn m...@plan99.net wrote:

 The bug is restricted - intentional?
 
 I'm guessing this is class data sharing and would make startup of packaged 
 apps faster?
 
 On Tue, Mar 31, 2015 at 12:52 AM, Chris Bensen chris.ben...@oracle.com 
 wrote:
 +1
 
 On Mar 30, 2015, at 3:11 PM, Danno Ferrin danno.fer...@oracle.com wrote:
 
  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: Review Request: RT-39975 - AppCDS support for packager

2015-03-31 Thread Chris Bensen
No, I don’t have any stats to share about the performance benefits, sorry.


On Mar 31, 2015, at 1:42 PM, Mike Hearn m...@plan99.net wrote:

 Do you have any stats on the perf improvement? My understanding of CDS is 
 that it was primarily meant to reduce memory usage on systems where multiple 
 Java apps are running on the same JRE simultaneously. I guess that won't 
 apply to packaged apps so the only benefit can be startup time.
 
 On Tue, Mar 31, 2015 at 3:59 PM, Chris Bensen chris.ben...@oracle.com wrote:
 Correct!
 
 
 On Mar 31, 2015, at 4:41 AM, Mike Hearn m...@plan99.net wrote:
 
 The bug is restricted - intentional?
 
 I'm guessing this is class data sharing and would make startup of packaged 
 apps faster?
 
 On Tue, Mar 31, 2015 at 12:52 AM, Chris Bensen chris.ben...@oracle.com 
 wrote:
 +1
 
 On Mar 30, 2015, at 3:11 PM, Danno Ferrin danno.fer...@oracle.com wrote:
 
  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: Review Request: RT-39975 - AppCDS support for packager

2015-03-30 Thread Chris Bensen
+1

On Mar 30, 2015, at 3:11 PM, Danno Ferrin danno.fer...@oracle.com wrote:

 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: [8u40] review request: RT-39182: Enable building 32-bit Linux on 64-bit systems

2014-11-24 Thread Chris Bensen
+1

On Nov 22, 2014, at 5:29 PM, Kevin Rushforth kevin.rushfo...@oracle.com wrote:

 Dave, Kirill, Anton, Chris,
 
 Please review the following build changes to enable building 32-bit graphics, 
 media, webkit, and packager binaries on a 64-bit Linux system.
 
 https://javafx-jira.kenai.com/browse/RT-39182
 http://cr.openjdk.java.net/~kcr/RT-39182/webrev.01/
 
 Details are in JIRA.
 
 -- Kevin
 



Review for RT-39137

2014-11-12 Thread Chris Bensen
Danno, 

Please review this patch.  More info in the JIRA

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


Re: Review for RT-38968

2014-10-13 Thread Chris Bensen
From what I’ve seen, jvmuserarg.0 never exists. It is 1 based. If you are 
however changing it to 0 based then this line is fine:

-TString prefix = TString(_T(jvmuserarg.)) + 
PlatformString(index).toString();
+TString prefix = TString(_T(jvmuserarg.)) + PlatformString(index + 
1).toString();
Otherwise it is not.

Chris



On Oct 13, 2014, at 1:23 PM, Danno Ferrin danno.fer...@oracle.com wrote:

 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



  1   2   >