Had some trouble understanding the "why?" of these answers and their differences and wanted to give an explainer/re-summation based on my additional 1 hour rabbit hole for anyone else based on when each is needed. First,
maven-jar-plugin - create a jar of ONLY your codemaven-assembly-plugin - create a jar of your code AND direct copies of all the code you used. (also, it can do additional weird packaging requirements afterwards)maven-shade-plugin - create a jar of your code AND direct copies of all the code you used AND rename/refactor all of that other code to prevent potential naming conflicts from other uber jar libraries being used concurrently.My main question was why were all 3 still actively maintained, if the shade-plugin is just better, why bother with the others existing? And the answer seems to lie in the three different audiences that these libraries assist.
Any traditional library being uploaded to a maven repo is going to aim for an emphasis on the slimmest possible jar ONLY containing their requirements, instead leaning on the pom.xml to define what people should download from elsewhere. (avoiding the nightmare of shipping every package)
When I personally wanted to ship a quick executable jar for a script I was using along with a runtime I leaned on the assembly jar. It can effectively package up a fat-jar with all the dependent classes from other jars copied into your main jar, but also can do additional steps after, like taking the jar, and a jre, and some helpdocs into a zip file, that's the assembly plugin's strength.
The assembly plugin is also much more straightforward, it does basic dependency management and packaging and that's it, it was published earlier (version 2.0 was published to mvnrepository in 2006 2 years before shade v1.0) and shade came later with a much more complicated problem to solve.
Ok now, the final use case, the so called uber or shaded jar (have seen it referenced as both). this is for situations where you REALLY need an EXACT version of a library packaged with your library and know that other people may have a different version of the same library getting called.
In my case, I made it here from looking into using kotlin (and the kotlin std lib) with a minecraft server plugin and was curious why I needed to use shade for building. In that scenario, there will be a buuuuunch of other plugins all running similar versions of the kotlin std lib, but every one a diff version AND there is no dependency management like maven, my jar needs to ship pre-packed to drop and go.
This is where a so called uber-jar is needed that both needs to have all the dependencies packed in but also needs to not conflict with other versions, even the assembly plugin says it cannot effectively manage this requirement:
If your project wants to package your artifact in an uber-jar, the assembly plugin provides only basic support. For more control, use the Maven Shade Plugin.
This is the entire purpose of the shade plugin, it creates a jar with all the dependency classes copied in BUT it also renames all those classes and refactors your code to match so that your classes will not conflict with any other classes in other libraries being imported elsewhere by the code. This is the only purpose of the shade plugin and is incredibly important, you could still use the assembly plugin after even to pack it all up in a zip or other things, but refactoring like that is not assembly's purpose.