shadowJar vs custom task

[silvanheller]

I added the shadowJar Plugin on dev to replace the current custom fatJar task. I see multiple advantadges to removing the custom task:

• slimmer build-files
• having a library do the heavy lifting should make sure we get less edge-cases in which our custom task fails, also in the future.
• (the current taskname is suboptimal see e.g. ACM FAT renaming itself to ACM FAcct, but we could also rename the current task...)
• cottontail also uses it

Are there any reasons to keep the current custom task for v3.1.0 and not switching to shadowJar?

[lucaro]

I'm not familiar with the exact way of operation of shadowJar. Does it allow for the production of two versions of the jar, one completely self contained and one with only the code of this repository, as well? If so, I'm all for using standardized packages over custom tasks.

[sauterl]

The plugin uses a different terminology: the shadow jar will be what we previously referred to as fat jar. The default gradle jar task will produce a jar with only code from the repository, while the shadowJar task will produce the fat jar with all dependencies in it, ready to be executed

[lucaro]

Sounds good, let's do that then.

[sauterl]

I think this is a good idea, the flexibility to change the main class for the api and runtime submodules still remains and we'll still be able to have two jars - one with all the deps and one without