understanding goal exec in maven - maven

Question

I'm trying to create a native installer for javafx 8 application using the fxlauncher as explained at http://fxldemo.tornado.no/
In the pom.xml provided with the example, I do not understand what the execution embed-manifest-in-launcher is doing.
Question: Could someone please explain whats happening there?
The first execution is straight forward, it has specified a java class which has main method and provided the arguments.
<execution>
<id>create-manifest</id>
<phase>package</phase>
<goals>
<goal>java</goal>
</goals>
<configuration>
<mainClass>fxlauncher.CreateManifest</mainClass>
<arguments>
<argument>${app.url}</argument>
<argument>${app.mainClass}</argument>
<argument>${app.dir}</argument>
</arguments>
</configuration>
</execution>
<!-- Embed app.xml inside fxlauncher.xml so we don't need to reference app.xml
to start the app -->
<execution>
<id>embed-manifest-in-launcher</id>
<phase>package</phase>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<executable>jar</executable>
<workingDirectory>${app.dir}</workingDirectory>
<arguments>
<argument>uf</argument>
<argument>fxlauncher.jar</argument>
<argument>app.xml</argument>
</arguments>
</configuration>
</execution>

Answer 1

The comment just above the execution is already providing a first hint:
Embed app.xml inside fxlauncher.xml so we don't need to reference app.xml to start the app
The executable configuration entry is set to jar, so it will run the jar command.
It will then pass to it the parameters uf, from the jar help command we can see that:
-u update existing archive
-f specify archive file name
Hence, the f option is also expecting a parameter, which is indeed the fxlauncher.jar entry.
As such, the full command which will be executed would be:
jar uf fxlauncher.jar app.xml
Which will update the existing and provided fxlauncher.jar file adding to the app.xml file, as per comment above.
Such execution has a binding to the package phase in a project with packaging jar (the default one, hence no need to specify it), which will be executed after the default bindings to this packaging for this phase (the Maven Jar Plugin, for instance). Hence the build will firstly create/package the jar file, then run these executions to change/update it.