Re: Disabling jarHell for plugins

This mailing list does not send out an email to the original poster, so
hopefully I can reply to my own sent email.

Shading jars will not work due to the way the plugin distribution is built.
You cannot create an uber jar since the original runtime dependencies will
always be included:

Can jar hell be disabled for testing?



Jar hell checking cannot be disabled. But it is not clear to me from this post what problem you are trying to solve. If you have a conflict with ES core, you need to resolve that. Shading can work, you just need to add the dep in a separate configuration, then shade those dep jars together, either into another runtime jar, or into your plugin's jar itself.

The issue solely resides in the Derby dependencies which contain Java
classes that overlap.

I can create my own configuration which will remove the specified
dependencies from the plugin zip file, but the bundle task only knows about
the original jar file and not the shaded jar (created via shadowJar)

Zip bundle = project.tasks.create(name: 'bundlePlugin', type: Zip,
dependsOn: [project.jar, buildProperties]) {
from project.jar // this plugin's jar

Tried to get around it by "overriding" the jar task, but it does not work
(as expected)

jar {

One possibility is to disregard the scaffolding the the plugin plugin
provides and do my own bundling. All I need really is to disable jar shell
on the test cluster. :slight_smile: Or just do away with integration tests.



This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.