We should rebrand the javafxpackager as just the java packager. It is useful for Swing, AWT, SWT, and (now) headless apps so the branding shouldn't indicate that it is just a JavaFX feature. To that end:
* Rename javafxpackager to javapackager
* Move APIs that will have long life to com.oracle.java.tools.packager (such as the new bundler APIs)
To preserve backwards compatibility:
* Put in a stub javafxpackager that fails and points the user to the new javapackager binary.
* Keep only classes that are not part of the new bundler API where they are, and keep some classes that are key to backwards compatibility in place, such as PackagerLib and related classes.
* Some files may live in two places, with one deprecated. Such as the antlib.xml
Compatibility with the most recent versions of the following tools should be maintained:
* Ant scripts that worked on Java 1.8
* zonski's Maven plugin (http://github.com/zonski/javafx-maven-plugin/)
* shemnon's Gradle Plugin (https://bitbucket.org/shemnon/javafx-gradle/)
* Rename javafxpackager to javapackager
* Move APIs that will have long life to com.oracle.java.tools.packager (such as the new bundler APIs)
To preserve backwards compatibility:
* Put in a stub javafxpackager that fails and points the user to the new javapackager binary.
* Keep only classes that are not part of the new bundler API where they are, and keep some classes that are key to backwards compatibility in place, such as PackagerLib and related classes.
* Some files may live in two places, with one deprecated. Such as the antlib.xml
Compatibility with the most recent versions of the following tools should be maintained:
* Ant scripts that worked on Java 1.8
* zonski's Maven plugin (http://github.com/zonski/javafx-maven-plugin/)
* shemnon's Gradle Plugin (https://bitbucket.org/shemnon/javafx-gradle/)