I second this approach. It's much more simple, maintainble and you retain
the ability to monkeypatch production deployments. You can later chain it
into assembly plugin to produce an archive that contains your launch
scripts, dependencies, configurations, and perhaps even the JDK itself. If
youre against having launchscripts, you can write classpath into manifest
via archive plugin.
I doubt that uberjars should be used as dependencies at all considering
they usually suffer from split package issue. If yours doesnt, it probably
uses some special classloader, which makes runtime much more complex than
it needs to be.
On Sun, Apr 25, 2021, 12:45 Jim N <northrup.ja...@gmail.com> wrote:
> there's nothing that really painlessly replaced the first
> maven fatjar since it became outmoded.
>
> that said, i use dependency plugin to dump a lib/ dir even for reactor
> builds, and then a shell script that uses that classpath syntax to load a
> directory at a time.
>
> this happens with maven exec anyways, just less fragile.
>
> sometimes shade chokes on a manifest glitch and in practice fixing that is
> less efficient than a robust lib/ dir
>
> in the parent-most pom if the levels go deeper, verbatim from the
> dependency plugin docs, is
> ```!xml
> <plugins>
> <plugin>
> <artifactId>maven-dependency-plugin</artifactId>
> <executions>
> <execution>
> <phase>install</phase>
> <goals>
> <goal>copy-dependencies</goal>
> </goals>
> <configuration>
>
> <outputDirectory>${project.build.directory}/lib</outputDirectory>
> </configuration>
> </execution>
> </executions>
> </plugin>
> ```
> in bin/ of the top level i have the tiniest specific bash runner, easily
> ported to windows as well.
>
> ```!bash
> #!/usr/bin/env bash
>
> set -fx
> JDIR=$(dirname $0)/../apprunner
> exec java -classpath "$JDIR/target/*:$JDIR/target/lib/*"
> ${EXECMAIN:=apprunner.MyMain} "$@"
> ```
>
> often it's a helpful thing to keep these shell scripts handy to record
> variaous -XX and -D parameters in the comments or at run time.
>
