Release Process

[puce77]

This is a discussion about the release process and how the JavaFX Maven Plugin could support it.

I don't have the full picture about native installers yet, but since you're planning some bigger changes (https://twitter.com/FibreFoX/status/820335033143664640) I think it would be good to take also the following ideas into consideration.

When you perform a release (usually with the Maven Release Plugin or the Maven JGit-Flow Plugin) typically the following steps are processed in one order or another:

• Some special release Maven Profiles might be set active
• The version is set to a non Snapshot version.
• The source gets tagged in the SCM
• The release artifact are generated, often signed and deployed to a Maven Repository Manager (for applications this is usually a private one, not Maven Central).
• The version is set to the next Snapshot version

The trouble with the javapackager, AFAIK, is that you cannot generate all release artifacts for all platforms in one run (on one platform).

So you have to run the build on every supported platform again, either manually or using a CI server with dedicated slave agents, each running a different OS.

I think for each platform this would currently require to:

• Clone the source repository
• Switch to the tagged version (you need to know the tag name)
• Rebuild the app directory (you might have to know the Maven Profiles which were active during releasing to get the same output)
• Generate the OS specific native installers

But even if you would do all this, your native installers wouldn't include the release articats but some re-generated ones (think e.g. about a multi module application project here). This is generally not what one wants as the artifacts can then differ in content (depending on the active Maven Profiles ; error-prone), timestamps, MD5 sums etc.

So maybe the JavaFX Maven Plugin could provide two additional goals:

1. a goal to package everything needed for a native installer build - a zip of the app directory + zips for each OS containing the OS specific resources and configurations. It should be possible to attach these artifacts to the project as secondary artifacts. So when this goal is run during a release they get generated based on the tagged version and deployed to the Maven Repository Manager along with the other released artifacts of the build.

Please note that for server side applications, EAR and WAR files also usually get deployed to the Maven Repository Manager. To deploy a ZIP file including the app directory content wouldn't be so much different.

What is different are the OS specific source ZIPs, which leads us to the next proposed goal:

2. a goal which, similar to the build-native goal, can generate native installers, but works on the released and deployed artifacts of goal 1. rather than on the project sources.
   In fact, I think, no Maven project should be required at all for this goal. You wouldn't have to clone the source repositories on every platform and switch to the proper tag. You wouldn't have to generate all the artifacts and the app directory again.

What do you think?

[FibreFoX]

Yes, you are right, there is a huge problem with the same project being required to be built on several machines, and yes, it comes from the concept of the JDK itself, which the javafx-maven-plugin has to fight against. The documentation lists that problem as "drawback":
7.2 Benefits and Drawbacks of Self-Contained Application Packages

Package per target platform

Self-contained application packages are platform-specific and can only be produced for the same system on which you build. To deliver self-contained application packages on Windows, Linux, and OS X, you must build your project on all three platforms.

For the release-part I often tend to create all JARs with non-SNAPSHOT versions first, and having a "bundle-project", where all created JARs are declared as dependencies.

I've thought about the whole process too, even tried to think about re-implementing the whole bundler-process from scratch. Might be worth it, but I fear to just add an additional layer of "yet another build-tool", and I have still the system-architecture problem, because of the packaged binaries (on 64bit installations, there is no 32bit binary included).

There is even an existing bug reported about the 32bit and 64bit-problem:
Native installers - provide a way to build a 32bit installer with 64bit JDK (and vice versa)

Your requested feature about the javapackager providing a clean way for producing all outcomes on the same platform even got his own bug, but got rejected:
Native installers - provide a way to build all installers for all OS's on one OS

I fear that the situation is even more difficult than being solvable with this plugin.

[FibreFoX]

About the bundler-project: https://github.com/javafx-maven-plugin/javafx-maven-plugin/tree/master/src/it/16-multi-module-project

[FibreFoX]

Please note that for server side applications, EAR and WAR files also usually get deployed to the Maven Repository Manager. To deploy a ZIP file including the app directory content wouldn't be so much different.

If I understood correctly, you want the generated files being part of the artifacts, right? This would mean that the user will have to use a separate <packaging>-type of you projects. But unfortunately this might be not reproducable, because the tooling depends on the locally installed software, which might just fail/work different than expected, or would fail on windows due to AV-software not allowing to swap the executable icon.

The risk to generate something not working as artifact is very high.

[puce77]

I'm not sure if I understand all your points. And I'm not sure you need a custom packaging-type for this. E.g. the Maven Super POM is configured to generate secondary JAR artifacts for sources and javadoc when you set performRelease=true using goals of the Maven Source Plugin and Maven Javadoc Plugin. Basically we would need a zip of target/jfx/app and a zip of src/main/deploy, I think. If they are generated by an additional goal rather than by build-jar, you could put the execution in a Maven profile which is active when performRelease=true. Or you could add a property to build-jar which one can enable/ disable if performRelease=true/false. But build-jar does already a lot of stuff, maybe it would be good not to pack more into this goal.

[puce77]

For the second goal you would then call on every supported platform something like:
mvn jfx:buid-native-2 -DappZipArtifact=myGroupId:myArtifactId:app-zip:myVersion -DdeployZipArtifact=myGroupId:myArtifactId:deploy-zip:myVersion

The goal would download these artifacts unzip them to a tmp directory set them as source for app and deploy and the rest should be the same as for build-native.

Of course we have to find a better name than buid-native-2 ;-)

[puce77]

The test-jar goal of Maven JAR Plugin does something similar, I think, for test jar. And the copy goal of the Maven Dependency Plugin can download artifacts without a Maven project as well, AFAIK.

[FibreFoX]

As mentioned before, you can split the creation of the jar-files and the creation of the installers/native launchers, just by creating a "app-bundler" project, where you just can reuse all your already released jar-files.

As there is no clear RELEASE-strategy introduced with javapackager, this plugin won't introduce this.

Creating a "package" like you proposed won't be possible, as all these files are stored inside the JDK-jars, and are not part of this maven-plugin.

I know, that my answers are frustrating, but take it from my perspective: this maven-plugin only gives a "more or less simple" maven-wrapper, to avoid using the javapackager-executable and it's xml-configuration.
There are a lot of "bugs" inside the javapackager-concepts, like the detection of the .cfg bootstraping-files, or the file-structures, and especially the ability to customize the whole bundling-process.

For a more specific release-development-cycle supporting it might be interesting to tinker a NEW maven-plugin which is specialized into creating INSTALLERS.

[puce77]

I'm not confident an "app-bundler" project will make things much easier.

Also the new maven-plugin approach is not very feasable, as for this the execution of Bundlers is required, which the JavaFX Maven Plugin takes care of.

I think I will try to put something together when I find some time as it might be easier to talk about some actual code.

It looks like there are some misunderstandings. One of the requirements is to have a "build-jar" which doesn't require a Maven project to be present. A Maven project is not something the javapackager requires but just a design decision of the "build-native" goal. I don't want to change that. Just add an extra goal which doesn't require a Maven project to be present and might be easier to use in a release process than the "build-native" goal. Also I don't plan to include anything JDK specific (not sure about the packager.jar, though. Is it platform independent?).

[FibreFoX]

The packager.jar comes from the JDK and is independant (its a jar-file which only adds some classes for accessing the special values), but it does load a special file, which is required to lay aside of the native launcher: https://github.com/teamfx/openjfx-8u-dev-rt/blob/master/modules/fxpackager/src/main/java/jdk/packager/services/userjvmoptions/LauncherUserJvmOptions.java#L53

I did understand your idea, and the javafx-maven-plugin was created with no <executions>-support (I added it with some of my first PRs on this project), which means that a full development-cycle isn't designed to be supported.

If this "CI-server"-feature is required, it means that the plugin needs to be completely rewritten, maybe even requires to replace the javapackager itself.