[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: Platform independent deployment
From:       John Hendrikx <john.hendrikx () gmail ! com>
Date:       2022-10-21 19:27:55
Message-ID: 412cd227-dc49-5467-b950-1b1b32b50e68 () gmail ! com
[Download RAW message or body]

On 21/10/2022 18:04, Thomas Reinhardt 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". 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.

This is exactly how I package my stuff.  You get a jar, with everything 
in it which runs on all the platforms.

I include these dependencies in Maven, AFAIK the rest isn't platfrom 
dependent:

     <dependency>
       <groupId>org.openjfx</groupId>
       <artifactId>javafx-graphics</artifactId>
       <classifier>win</classifier>
     </dependency>
     <dependency>
       <groupId>org.openjfx</groupId>
       <artifactId>javafx-graphics</artifactId>
       <classifier>linux</classifier>
     </dependency>
     <dependency>
       <groupId>org.openjfx</groupId>
       <artifactId>javafx-graphics</artifactId>
       <classifier>mac</classifier>
     </dependency>

Then just package the whole bunch with the shade plugin:

       <plugin>
         <groupId>org.apache.maven.plugins</groupId>
         <artifactId>maven-shade-plugin</artifactId>
         <executions>
           <execution>
             <goals>
               <goal>shade</goal>
             </goals>
             <configuration>
<shadedArtifactAttached>true</shadedArtifactAttached>
               <transformers>
                 <transformer 
implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<mainClass>hs.mediasystem.local.client.NonJavaFXFrontEndRunner</mainClass>
                 </transformer>
               </transformers>
             </configuration>
           </execution>
         </executions>
       </plugin>

This yields a fat jar.  When you unzip it, all JavaFX classes, all 
native libraries etc. are included, and it runs without any special 
command line arguments.

>
> 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.

Nor is mine, and I never intend to modularize it, and it will never be 
needed as long as there are source files.

I even use this to avoid the modularize startup that JavaFX seemingly 
enforces:

     public class NonJavaFXFrontEndRunner {
       public static void main(String[] args) {
         FrontEndRunner.main(args);  // Workaround for javafx.graphics 
named module check when bundled as fat jar
       }
     }

Where FrontEndRunner has another main entry point which implements 
Application:

     public class FrontEndRunner extends Application {

       public static void main(String[] args) {
         System.setProperty("prism.lcdtext", "false");

         Application.launch(args);
       }

>
> 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?
>
>
> Seriously, isn't the sole existence of this plugin an indicator that 
> something is not quite right?

I'm not sure what, I never needed this plugin, and I agree, needing a 
specific plugin for a dependency would be odd, but turns out you don't 
need it :)

--John


[prev in list] [next in list] [prev in thread] [next in thread]