Recommended way to resolve classpath incompatibilities between plugin code and IntelliJ SDK

Answered

I am having some problems with our plugin using a newer version of the PicoContainer which is incompatible with the one used in Intellij.

Our plugin uses PicoContainer 2.X while Intellij IDEA still uses 1.x. Due to the API restructuring that was part of the major release, the libraries are not compatible. In our plugin, we avoid this problem by modifying the classpath to only contain our version of the library when building the plugin. This is not a very good solution and leads to more workarounds (building using the gradle-intellij-plugin gets somewhat difficult), but it works for now for building and running the plugin. We would like to avoid such workarounds but haven't figured our a better solution yet.

The issue now is that I would like to add some tests using IntelliJ test-fixtures. These test-fixtures rely on the old version of the PicoContainer, meaning they throw an exception when we try to use them with our setup. The problem is that we would need the older version of the library to set up the test fixture but would then need the newer version of the library to execute the plugin tests.

Is there any way of avoiding/solving this library conflict (besides not using the PicoContainer 2.X in our plugin) in general? (This would really help us to clean up our build process.)
If not, is there a way of solving the library conflict when using the test fixtures (except patching the classpath at runtime)?

As a side note: There are already two forum entries about this by two former developers of ours back in 2014 [1][2], meaning this is technically a duplication. But since they did not get any traction back then and are pretty old, I decided to open a new entry instead.

2 comments
Comment actions Permalink

Hello Tobias,

I'm sorry for the late reply. Unfortunately, I don't see a good solution for this problem now. IntelliJ Platform heavily depends on PicoContainer library, and we don't plan to update it to PicoContainer 2.x in the foreseeable future. So bundling PicoContainer 2 with your plugin looks like the only option for me.

When you run tests, it loads all plugins' and platform's classes using the same ClassLoader, so conflicting versions will cause problems indeed. It's possible to solve this by using per-plugin classloaders, like we do in production. It's not a simple task, so don't expect this to be implemented soon, but I've created an issue about that so you can watch it to be notified about the progress.

0
Comment actions Permalink

For future reference if anyone else has this problem, we added a more functional workaround than manipulating the gradle-intellij-plugin build classpath:

We use the gradle plugin shadow to re-package the picocontainer library. This allows us to adjust the package names of the classes contained in the library, thereby avoiding the version conflict with the older library version used to build IntelliJ. If anyone is interested in the setup, it can be found here.

0

Please sign in to leave a comment.