Replace home-grown uberJar task with shadowJar plugin #4385
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Identify the Bug or Feature request
Addresses #4354
Description of the Change
This isn't a huge change, but is still kind of involved in its details.
The main change is switching away from
uberJar
in favour ofshadowJar
in order to gain support for service file merging. This fixes SPI registration for our dependencies, including Graal languages (JS, regex), andjai-imageio-jpeg2000
(which we had a workaround for that is now removed). There was also a bunch of other stuff that was missing but is now present in the service files. Here's a complete diff of the service files for those interested:Outside of
META-INF/services/
, theshadowJar
task only keeps one copy of any duplicated file. This is the same asuberJar
, but the two don't necessarily pick the same copy. Mainly this happens with many unimportant text files, but I also noticed that there were differences in class files as well. Looking into this, I found that there was a conflict between our dependenciescom.github.jai-imageio:jai-imageio-jpeg2000
andedu.ucar:jj2000
. The latter comes from fromtika-parser
, a redistribution of a very old version of a library which we don't actually need (we only use stuff fromtika-core
). So I switched to using an updatedtika-core
fromorg.apache.tika
instead, which avoids the conflicts while also reducing our dependency graph by a fair amount (315 -> 242).Possible Drawbacks
As mentioned, a different set of files are produce by
shadowJar
vsuberJar
. The differences should now be benign, but it is possible I overlooked something important. This can only impact the JAR release, not the other packaged releases.As far as I can tell,
tika-parsers
does not accomplish anything for us beyond whattika-core
provides. But if I'm wrong, this could negatively impact media type detection, and would affect the JAR release as well as the package releases.Documentation Notes
JS UDFs can now be used with the standalone JAR.
Release Notes
This change is