JavaPackager
JavaPackager copied to clipboard
Package from single platform to multiple platforms
Currently, the JDK path for other platforms needs to be specified manually, which means I have to download additional JDKs for Linux and Mac, because I am on Windows and enter their paths.
I am proposing a solution to automate this:
- Check which platforms we want to package for.
- Check if the JDKs for those platforms are already installed inside the temp folder.
- If not download and unpack them there (on Windows temp path could look like
this
C:\Users\<username>\AppData\Local\Temp\JavaPackager).
The jdkPath from the plugin config xml could then be removed or made optional.
Additionally, we would add optional jdkVersion (default 8) and jdkVendor (default temurin).
I already got the download logic and API stuff implemented for another project,
so could use it for this one too:

PR would be ready in 1 hour.
Note that the above would probably make it possible to package from windows to all other platforms, but not from linux/mac to all other platforms, since the necessary native tools are not available on those platforms I guess.
Hi @Osiris-Team!
I'm not really sure what you are proposing here ... I've read your changes in PR #248, but I don't know what are jdkVersion and jdkVendor for.
Do you want that JavaPackager downloads a JDK automatically (if it's not downloaded yet)?
jdkPath is already optional ... if not specified, JavaPackager uses the current JDK (java.home).
jdkVersion can be 8 for example and specifies the jdk version that gets downloaded.
So this should be set to the project jdk version optimally or something lower.
jdkVendor is the prefered vendor to download the jdk from. I am using the public download APIs of those vendors. In this case its only https://adoptium.net/
Do you want that JavaPackager downloads a JDK automatically (if it's not downloaded yet)?
Yeah, so that it's possible to build from a single platform to multiple platforms without the need of downloading the respective jdks for those platforms manually.
How is this feature going on? I've tried to test pr-248 branch, but it seems you have some work in progress.
I plan to add some other features and patches, so hopefully we won't run into a painful merge 😅
yeah the actual PR with the auto-jdk download is already done. Was done within an hour max. Only thing that takes time is the settings for gradle/maven. I gave up on the idea of having one unified settings class, because maven won't work with it and I wasnt able to find the cause (fix the mojo already bound expection), so the only thing left was generating the classes.
This is already really painful though at the moment. I'm thinking of dropping this too and just stick to the old way. Only thing is that I already put a lot of thought and work into the generator...
I gave up on the idea of having one unified settings class, because maven won't work with it
Have you considered utilizing Maven's toolchains feature? It would require someone to add an entry into their maven toolchains.xml file, but it could be utilized to target a specific JDK for a build.
One thing that puzzles me is that I thought it was required that each platform must be packaged from that platform's operating system. Is this not the case?
@EasyG0ing1 Guess you only need the platform-specific JDK and nothing more if you are building from windows to everything else. If u try from linux to windows it still wont work I think.
@fvarrui Managed to avoid the MojoExecutionException for maven, and now got a pretty nice structure (see MavenPackageTask and GradlePackageTask and PackageTask classes in my branch) Maven is almost working, now there are gradle issues hower, gotta find another solution for that. *Update found a solution and code is now working https://github.com/fvarrui/JavaPackager/compare/devel...pr-248
Guess you only need the platform-specific JDK and nothing more if you are building from windows to everything else. If u try from linux to windows it still wont work I think.
@Osiris-Team Interesting, I'm now wondering what it is about windows that makes it easier for packagers to reference JDKs from the other platforms while it's not as easy to go the other way ... or maybe it's just a lack of anyone writing the packaging software for the other platforms (mac / Linux).