> I doubt that uberjars should be used as dependencies at all I disagree. There are tons of valid usage scenarios. Look at AspectJ runtime, AspectJ tools (compiler), AspectJ weaver, dozens of Java agents which might contain relocated classes from ASM and/or Byte Buddy etc. You want to use those, you want to test those and consequently depend on those. Maybe your world is as simple as your IMO over-simplifying statement suggests, mine is not.
I really would appreciate conrete answers to my questions instead of philosophical discussions about the Maven Way, spiced up with suggestions to script my build, which is exactly *not* the Maven Way. -- Alexander Kriegisch https://scrum-master.de Mantas Gridinas schrieb am 25.04.2021 17:24 (GMT +07:00): > 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. >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
