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
