This last parameter is the most relevant one for future-proofing the plugin. Added a bundleArguments parameter, following the Maven map conventions, so you can pass arbitrary configurations to any of the bundlers.Added a userJvmArgs parameter, following the Maven map conventions, so you can provide JVM arguments that can be adjusted by the application at runtime.Added an appName parameter so you can customize the app name independent of the Maven project name.Added needsShortcut and needsMenu parameter to set the presence of a launch/start menu icon or a desktop icon for bundlers that support it.There as some existing JavaFXPackager configuration options that have been exposed to the plugin in the config element. But the 8.1 version of the plugin and anything less than 8u20 doesn’t work, similarly with 2.0 and anything after 8u11. The 8.1 and 8.2 versions may work with each other, and they may not. When 8u40 comes out, a new 8.2 version will be released, so on with 8.3 and 8u60 and so on.
#JAVAFX OPEN RECENT MENU SERIES#
The 8.1 series will work with 8u20 through any version less than 8u40. The 2.0 line works with Java 7 and Java 8, 8u5, and 8u11. This means that some lineages of the plugin will become ‘version-locked’ with the particular versions of the JDK.
packages in the JavaFX modules that start with com.sun and com.oracle such breakage should not be suprising as Sun, and then Oracle, has expressly reserved that right. Since this plugin is dependant on ‘internal’ Java APIs, e.g. A lot of internal structure was changed to make sure that the java packager could be used directly by IDEs and other build tools, and as a consequence some binary compatibility was broken. The major feature of this release is compatibility with the changes done in Java 8u20. On the same note, patches that help the plugin live together with other plugins will be favorably considered. I think there is enough space for packaging plugins that don’t make self-contained native applications and JNLP packages. Patches that move the plugin from this lean-and-mean approach will be politely declined.
#JAVAFX OPEN RECENT MENU MAC#
In fact, it can help you put Swing applications on the Mac App Store. The Java Packager can still be used to package JavaFX applications, but it can also package SWT applicaitons, AWT applicaitons, headless applications, and good old Swing applications. This plugin now exists as a means for Maven to access the features of the Java Packager, which started life as the JavaFX Packager. This also represents a change in philosophy for the plugin. Already a lot of the changes in this release come from community members. It does not mean that I am the only one allowed to write code. That means I am responsible for getting the binary bits onto Maven central. New MaintainerĮffective with the 8.x series of the Maven JavaFX Plugin, and with the consent of Daniel Zwolenski, I am now maintaining the project. Existing docs at are still mostly accurate. Docs are little sketchy since I need to find a new place to host them. This release provides compatibility with JDK 8u20, exposes new 8u20 features, and represents a change in maintainer. The Maven co-ordinates for the plugin are com.zenjava:javafx-maven-plugin:8.1.2, same as before just with an updated version number. Today I am announcing the release of the Maven JavaFX Plugin version 8.1. What happens when you combine them both? Lower priority items like making release announcements for your outside-of-work open source projects don’t happen on time.
Preparing multiple conference talks is also similarly time consuming. Deadlines on a shortened schedule are bad enough.
0 kommentar(er)
