How to fix jar version conflicts in JPS plugin

In my JPS plugin I depend on a third-party JAR that uses Apache Commons IO version 2.4. I've added the `commons-io-2.4.jar` to the `compileServer.plugin` `classPath` attribute, and can see it in the lib directory of the plugin. However, when I run the JPS plugin I eventually get a `java.lang.NoSuchMethodError:;[Ljava/lang/String;)Ljava/io/File`. It seems that the JPS build uses an older Commons IO version that takes precedence.

How can I ensure that my dependencies are used for my classes instead of the dependencies of JPS?

1 comment
Comment actions Permalink

Unfortunately there is no simple way to do this. Currently the external build process loads all JPS plugins in the same classloader, so commons-io library added to the classpath by Gradle plugin will interfere with your library. It is possible to add your version before Gradle's but this would probably break the Gradle plugin so it would be better to simply disable Gradle plugin instead if you don't need it.

So it seems that the only way to fix this is to create a classloader in your code by hand, add the desired version of commons-io to its classpath, and run it.



Please sign in to leave a comment.