On Fri, Oct 21, 2022 at 6:06 PM Thomas Reinhardt <thomas.reinha...@s4p.de> wrote:
> > I think there is a misunderstanding here. > > What I want is basically create a zip that contains all needed jars and > run my application via "java -jar myapp.jar". This assumes that end users have at least a JRE on their local machine, which is already platform dependent. So they already download platform dependent code, hence it makes sense to me that they also download platform dependent zips, no? But if you go one step beyond requiring a JRE, you could also require maven to be available locally, in which case you let maven download the required parts (and only those parts required at runtime for your specific OS). The even better option here, imho, is to use jpackage (which can also be invoked from the plugins) to build platform-specific applications. > Of course there exists a > proper exe for windows users etc but thats besides the point. The one > thing the whole discussion is about is that I want to use the same zip > for all supported platforms (linux and windows in my case). What I > specifically NOT want is platform dependent zips. We have a very large > number of dependencies and the size of the whole thing (zipped) is about > 300MB. Having os specific versions would basically double that size for > our nexus instance, the download server etc. > I agree different versions would lead to more disk space on your nexus if you have 300MB jars. But apart from that, a single version would be annoying for users. They will have to download OS-specific libraries that are useless on their machines. For example, the native libs required for webkit are about 100MB. If you are going to bundle only the desktop ones (linux/win/mac arm/amd) you will have about 600MB already, of which 500MB is useless. Apart from requiring more diskspace for the end user, it will also increase the data transfer drastically. > > To be clear: the whole thing has to run on the classpath and is not > modularized (yet). Not what we want but what other dependencies are > forcing us to do. > That's fine -- happens often and not much you can do about it. > > > If I read the source correctly, the javafx-maven-plugin can either run > the application on my dev machine (why?) or create platform dependent > runtime images. > Am I missing something? > I still think the platform dependent runtime images (or the platform independent pom files) are the best approach. The only drawback I see is that indeed those images will then consume disk space on your nexus. > Seriously, isn't the sole existence of this plugin an indicator that > something is not quite right? > I don't see why. The goal of OpenJFX is to deliver the JavaFX code, which has a platform independent Java API and a number of implementations that contain a mix of platform independent Java code, platform dependent Java code, and platform dependent native code. This is the same situation as in OpenJDK. The plugins allow developers to deal with this relative complexity, but they solve a different problem. Since there are different requirements for different environments (e.g. some environments do not allow a JVM), there is no one size fits all. The javafx maven/gradle plugins in github mainly help developer use cases, and allow for bundling required mods with jlink in a platform-dependent bundle. If you go one step further, the Gluon plugins allow to pre-compile everything ahead of time and bundle everything in a binary that doesn't require/bundles a JVM (see https://github.com/gluonhq/gluonfx-maven-plugin and https://github.com/gluonhq/gluonfx-gradle-plugin). We don't have these plugins because the concepts in OpenJFX are broken, but they make life of a large number of developers and users easier. Granted, they don't cover all use cases. The specific case you talk about where you want to have a zip with all native libs combined is not out of the box covered, but it can easily be added -- I just don't think this usecase is very common for the reasons I already mentioned. > > Again, apologies if this sounds personal or unfriendly in any way. Not > intended at all. > Don't worry, no problem at all, it's good to ask and discuss those things! > > > -Thomas > > > > > > > > On 21/10/2022 11:54, Johan Vos wrote: > > > > > > On Fri, Oct 21, 2022 at 11:38 AM Thomas Reinhardt > > <thomas.reinha...@s4p.de <mailto:thomas.reinha...@s4p.de>> wrote: > > > > > > As for the javafx-maven-plugin: I don't see how this would help > > here. It > > states on the github page "JavaFX dependencies are added as usual". > > > > > > ... but you don't have to add a classifier (or an exhaustive list of > > classifiers) as that is what the plugin takes care about. Hence: you > > just depend on javafx.controls and you don't mention > > javafx.controls:linux-x86_64 etc in your pom at all. > > > > Unless I'm missing something, I don't see the problem (no need for > > having 12 dependencies instead of 2). > > > > - Johan >
