Re: EventHandler not working in 11.0.2
IntelliJ's code completion looks to be wrong then. Just delete the "(EventHandler)" On 27/03/2019 18:29, Andrew Munn wrote: How do I listen for mouse events in 11.0.2? IntelliJ's code completion suggests this: textField.addEventHandler(MouseEvent.MOUSE_ENTERED, (EventHandler) t -> { // do something }); but it fails to compile with error: cannot find symbol T Thanks
Re: Filling the Packager gap - again
There have been updates since then. In particular, you can now find it hosted here: https://jdk.java.net/jpackage/ What you download is an EA build of jdk-13 which includes jpackage. You just use the jpackage that's in that. (You don't have to use that JDK for anything else, just literally set a path to that jpackage binary and run it.) Up to date options in the JEP: https://bugs.openjdk.java.net/browse/JDK-8200758 No idea if the latest fixes your issues. I'm currently only using it on Windows where (with a bit of fighting) it's working "good enough for now", although updates don't remove the previously installed version of your app from the registry like they should yet. -- Rachel On 13/01/2019 12:44, Kustaa Nyholm wrote: Hi, I've been struggling with packaging my app on MacOs High Sierra (10.13.6) with OpenJDK 11.0.1 Literally I've put days into this. Won't bore you will all the details (unless you want) but my latest attempt is based on this and hence I'm addressing this list: https://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022500.html Specifically I downloaded http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip and copied: jpackager -> /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/bin jdk.packager.jar -> /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/bin I also have (copied from jdk1.8.0_102): /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/lib/ant-javafx.jar The build works in that it produces a working .dmg and .app with correct icons and all ' (in /private/var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/fxbundler7020007958604602553/images/EazyCNC-tmp.dmg etc) but the build ends with an unspecified failure (unless it is related to the 'already an item with that name.'): Building DMG package for EazyCNC Using custom package resource [Bundle config file] (loaded from package/macosx/Info.plist) Using custom package resource [icon] (loaded from package/macosx/EazyCNC.icns) Did not find a key matching 'Developer ID Application: ' Config files are saved to /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/fxbundler18114117913034428425/macosx. Use them to customize package. Using custom package resource [dmg background] (loaded from package/macosx/EazyCNC-background.png) Using custom package resource [volume icon] (loaded from package/macosx/EazyCNC-volume.icns) Using default package resource [script to run after application image is populated] (add package/macosx/EazyCNC-post-image.sh to the class path to customize) Using custom package resource [DMG setup script] (loaded from package/macosx/EazyCNC-dmg-setup.scpt) /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/fxbundler18114117913034428425/macosx/EazyCNC-dmg-setup.scpt:631:738: execution error: Finder got an error: The operation can’t be completed because there is already an item with that name. (-48) Config files are saved to /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/fxbundler18114117913034428425/macosx. Use them to customize package. BUILD FAILED /Users/nyholku/EazyCNC-Project/build.xml:305: Error: Bundler "DMG Installer" (dmg) failed to produce a bundle. Total time: 6 seconds Any suggestions to how to dig this further or anything would be highly appreciated. I'm pretty sure I've tried all the workarounds and suggestions that google can find. wbr Kusti
Re: Using the jpackager
None, that's just my own class task in buildSrc. It's a fairly trivial wrapper around a ToolProvider invocation of jlink, so I didn't think it was relevant enough to paste the source for that here too, when you could also do it trivially with an Exec task similar to the jpackager ones later in my first reply. It's literally public class JLink extends DefaultTask with a bunch of getters and setters for the options and a run method that turns them into arguments and invokes via ToolProvider. The same task type is also used elsewhere in the root project to build the server JRE for the server component of this project, which was enough to make it worthwhile writing the task. (I also wanted to learn how to write java gradle tasks.) The point of the example I did paste was just about showing what options to set to jlink. jlink in any detail is offtopic here, this bit was just an illustration of using that to build the JRE first with the required modules, then use the result in jpackager to build a non-modular app. I would expect to write a similar simple task for jpackager too at some point, I just haven't yet. They may be the basis of a useful packager plugin, but probably not before jpackager itself is more mature. -- Rachel On 09/11/2018 21:34, Sverre Moe wrote: Den fre. 9. nov. 2018 kl. 16:22 skrev Rachel Greenham <mailto:rac...@merus.eu>>: Build the JRE needed using JLink, supplying the needed modules. The JLink task referenced is actually written in Java and wraps ToolProvider, but it's pretty trivial and could almost-more-easily be done with an Exec. NB: The JLink task as written puts it in a "java" subdirectory of the given destinationDir. task buildAdminJre(type: JLink) { description 'Build the Client JRE for ' + nativeOsName destinationDir rootProject.file("deploy/bindist/"+requiredJava.merusNativeAdminJreName) modules = [ 'java.base', 'java.desktop', 'java.xml', 'java.logging' ] bindServices false modulePath = [System.properties.getProperty('java.home')+File.separatorChar+'jmods'] noHeaderFiles true noManPages true stripDebug true } Which gradle plugin are you using that gives you type JLink?
Re: Using the jpackager
On 09/11/2018 15:20, Rachel Greenham wrote: Have the jar task build the application as normal. Here's mine as an example. The important part is, you don't need to build a single fat jar, but you can include the dependent jars with the Class-Path line below. Mine isn't a JavaFX app, so I don't know what it does now wrt pulling in the openjfx jars here, or whether you add them as modules to the jlink task above. I expect the former would be preferable. Correction, the *latter* would be preferable, of course. -- Rachel
Re: Using the jpackager
FWIW what I'm doing to build a windows app for jpackager, in terms of gradle tasks, that isn't modular. I hope this cleans up over time, but this is the final result of having just got the damn thing to work! :-) I think *eventually* we'll have a single call to jpackager do the whole lot. But I think we're not there yet, so it's split out into separate steps. You *will* need to make changes for your own context: Build the JRE needed using JLink, supplying the needed modules. The JLink task referenced is actually written in Java and wraps ToolProvider, but it's pretty trivial and could almost-more-easily be done with an Exec. NB: The JLink task as written puts it in a "java" subdirectory of the given destinationDir. task buildAdminJre(type: JLink) { description 'Build the Client JRE for ' + nativeOsName destinationDir rootProject.file("deploy/bindist/"+requiredJava.merusNativeAdminJreName) modules = [ 'java.base', 'java.desktop', 'java.xml', 'java.logging' ] bindServices false modulePath = [System.properties.getProperty('java.home')+File.separatorChar+'jmods'] noHeaderFiles true noManPages true stripDebug true } Have the jar task build the application as normal. Here's mine as an example. The important part is, you don't need to build a single fat jar, but you can include the dependent jars with the Class-Path line below. Mine isn't a JavaFX app, so I don't know what it does now wrt pulling in the openjfx jars here, or whether you add them as modules to the jlink task above. I expect the former would be preferable. /* Basic non-fat jar. */ jar { manifest { attributes( 'Product-Name': applicationName, 'Main-Class': mainClassName, 'Package-Title': project.group, 'Package-Vendor': vendor, 'Package-Version': adminVersion, 'Permissions': "all-permissions", 'Class-Path': configurations.runtimeClasspath.files.collect { it.getName() }.join(' ') ) } archiveName = 'adm.jar' } Build the application image. This should be mostly platform independent. (I think the only thing stopping it being is probably the .ico file for the icon.) Note I'm supplying as --input the lib dir from the target built by the standard gradle installDist task, so it contains the dependencies as well. adm.jar's manifest lists these as dependencies in Class-Path as per above. The JRE is supplied in the --runtime-image parameter. task createImage(type: Exec) { description 'Build the App Image for this platform using jpackager' dependsOn installDist dependsOn buildAdminJre def imageDir = "$buildDir/image" outputs.dir new File(imageDir,applicationName) commandLine 'jpackager', 'create-image', '--verbose', '--version',adminVersion, '--input', new File(installDist.outputs.files.singleFile,"lib"), '--output',imageDir, '--name',applicationName, '--description','', '--main-jar','adm.jar', '--class',mainClassName, '--icon','src/main/files/app-icon.ico', '--runtime-image',new File(buildAdminJre.outputs.files.singleFile,"java"), '--vendor',vendor } You'll now have the application image suitable for your platform. I've only tried this on Windows so far. Note: My app has a space in the applicationName value. This breaks at the moment. The following is a workaround task, split out for easy removal later when I'm sure it won't be necessary any more: task fixWindowsImage(type: Copy) { /* This task creates a copy of the image created by createImage task and fixes it up for using as the source of a Windows Installer. As of first writing, what this means is renaming a couple of files, because create-image crushes out spaces in the application name but we want them in, we have to rename the generated .exe and .cfg files to have that space again. Then msiInstaller will work to actually create the shortcut and start menu items. */ dependsOn createImage from createImage.outputs.files.singleFile into "$buildDir/fixedImage/$applicationName" rename (".exe", applicationName+".exe") rename (".cfg", applicationName+".cfg") } Then, as a separate stage, run the bit that puts it into an installer. So here the input supplied in --app-image is the complete application image as already created and fixed by the above tasks. task msiInstaller(type: Exec) { /* see fixWindowsImage for a necessary fix to the created application image to allow shortcut and startmenu items to work. */
JavaBeanObjectPropertyBuilder has incomplete generics support
javax.beans.property.adapter.JavaBeanObjectPropertyBuilder seems to be only partially adapted for generics. The class itself has a generic type (class JavaBeanObjectPropertyBuilder) and its build() method returns JavaBeanObjectProperty, but the lack of other support means you can't fluently create a property without also suppressing "unchecked" warnings. ie: One might want to do: private ObjectProperty ip4Property; ... this.ip4Property = JavaBeanObjectPropertyBuilder.create() .bean(server) .name("ip") .build(); but this will produce "unchecked" warnings during compilation. Harmless but annoying when you want to keep it clean. As it stands, to compile cleanly you need to split it up: var builder = new JavaBeanObjectPropertyBuilder(); builder.bean(server).name("ip"); // they return untyped builder this.ip4Property = builder.build(); ... or suppress the warning. I hate suppressing warnings. :-) Proposed fix: (I don't have an OpenJFX build environment yet, this is the first time I've wanted to change something!) * Each of the instance methods (except build()) to have declared return type JavaBeanObjectPropertyBuilder. This allows chaining those fluent builder methods without losing the generic type. * create() method to be: public static JavaBeanObjectPropertyBuilder create() { return new JavaBeanObjectPropertyBuilder(); } I think that's all it needs, and the latter only if you prefer to use the static builder factory method rather than just using the constructor directly. Then the first code example above would work cleanly as is. It also allows for callers to optionally explicitly specify the generic type to create() with eg: var builder = JavaBeanObjectPropertyBuilder.create(). As you can see all this is just generic type declarations, which should all be erased to cause no actual change to runtime. The effect on existing code should be null except that some people would be able to, if they want, remove the @SuppressWarnings ("unchecked") annotation they've so far had to put above it. -- Rachel
Re: Code review of jpackager tool (JEP 343)
ah. as i only followed this list to follow progress on this, turns out I'm in the wrong place. :-) -- Rachel On 24/10/2018 13:10, Kevin Rushforth wrote: The code review for the jpackager tool, JEP 343, is underway: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/056186.html The review is being done on the core-libs-...@openjdk.java.net mailing list, so please direct all feedback on the implementation of the JEP to that list. -- Kevin