I am currently trying to develop a plugin for IntelliJ that will use a "core" library*. The core library already has it's own dependencies (JAR files) and is used in other non-IntelliJ projects. Unfortunately some of the dependencies of the IntelliJ SDK are the same as that for the plugin core, but with conflicting versions. So far this has been manageable because we remove the dependencies in the SDK and provide the core's dependencies instead, and running the plugin through IntelliJ to work fine. However, I really want to be able to write automated unit tests for the plugin, and this causes problems.
Following the instructions from here, I set my first unit test to extend LightCodeInsightFixtureTestCase. However, this fails to get past the setUp method, throwing NoClassDefFoundErrors. See the gist of the error here (picocontainer is the conflicting dependency).
By inspecting the classes loaded while running the plugin, I can see that the same class from a conflicting dependency is loaded in two different classloaders, a URLClassLoader for the com.intellij dependency, a PluginClassLoader for my plugin's dependency. This explains why the plugin can be executed successfully, but the test fails.
My question is, what is the recommended way to resolve these conflicts that allows unit testing with the IntelliJ test fixtures?
Some possibly silly solutions I have thought of so far:
- figure out a way to use the same structure of classloaders within the tests (preferred solution)
- repackage the core libraries dependencies under a different namespace (seems a drastic step to take just to be able to unit test)
- give up on unit testing (gah!)
Any further suggestions, or pointers to ways other plugins have handled this, would be great.
* it's being ported from Eclipse, we don't want to build from scratch again for IntelliJ, instead we wish to separate and reuse the common code.