"idea.classpath.index.enabled" should be false in tests

[matklad]

idea.classpath.index.enabled is set to false in RunIdea task:
https://github.com/JetBrains/gradle-intellij-plugin/blob/master/src/main/groovy/org/jetbrains/intellij/RunIdeaTask.groovy#L45

However, for the test task it is true. The effect is that if I add a new class and run gradlew test, tests fail with NoClassDefFoundError. I can work around it by manually defining the property in the test task, but ideally the gradle plugin should do this automatically, or at least provide a method like setupSystemProperties.

P.S. I am new to gradle so this may be irrelevant, however I do receive NoClassDefFoundError in tests due to classpath.index

[zolotov]

Please provide as small as possible project sample and steps to reproduce the problem, I'll try to do something with it.

And just to make it clearer:

However, for the test task it is true.
ideally the gradle plugin should do this automatically

Plugin automatically and intentionally sets it to true.
The property should be true in tests. Actually this property was invented mostly for tests in order to make them faster.

at least provide a method like setupSystemProperties.

Since you can work around it by manually defining the property you don't need such method.

[matklad]

Please provide as small as possible project sample and steps to reproduce the problem, I'll try to do something with it.

I will do it, but I need some time. In the meantime here is the actual project where I am facing the issue: https://github.com/alexeykudinkin/intellij-rust .

Since you can work around it by manually defining the property you don't need such method.

Agree :) The point is that I've spent quite some time tracing the failing tests down to classpath.index file in the build directory. If the workaround is necessary, it is better advertised in the form of a documentation or API call.

[zolotov]

I've found how IDEA invalidates classpath.index, but still need some example to test.

https://github.com/JetBrains/intellij-community/blob/master/jps/jps-builders/src/org/jetbrains/jps/incremental/IncProjectBuilder.java#L351

[matklad]

Here you are: https://github.com/matklad/test-plugin

1. run gradle test
2. rename foo.Foo to foo.Bar (both in src and in test)
3. run gradle test again

foo.SimpleTest > testFoo FAILED
    java.lang.NoClassDefFoundError at SimpleTest.java:9
        Caused by: java.lang.ClassNotFoundException at SimpleTest.java:9

[zolotov]

Looks like the real speed up can be noticed on IDEA project only. It's easier to disable indexing classpath in tests.

Will be fixed in 0.0.27

[nicity]

this flag is needed for starting IDEA from IDEA

[zolotov]

@nicity flag is always false while running IDEA from IDEA in plugin-projects https://github.com/JetBrains/intellij-community/blob/master/plugins/devkit/src/run/PluginRunConfiguration.java#L143

[nicity]

Right, plugin-project is not IDEA project

[zolotov]

@nicity I thought that the flag is always true for tests but looks like I missed the condition about IDEA project here https://github.com/JetBrains/intellij-community/blob/master/plugins/devkit/src/run/JUnitDevKitPatcher.java#L50

There is no classloader customization for non-idea project, so the flag doesn't affect anything.

[nicity]

https://github.com/JetBrains/intellij-community/blob/master/platform/util/src/com/intellij/util/lang/UrlClassLoader.java#L46
https://github.com/JetBrains/intellij-community/blob/master/platform/util/src/com/intellij/util/lang/UrlClassLoader.java#L109

[zolotov]

@nicity and still we don't run IDEA from IDEA with UrlClassLoader, only tests in IDEA project

[nicity]

BootstrapClassLoaderUtil near word usePersistentClasspathIndexForLocalClassDirectories

[zolotov]

@nicity I see, thanks

[PawelLipski]

Huh looks that this problem is still there, probably with the new com.intellij.util.lang.PathClassLoader which puts classpath.index into build/classes/ all the time, thus effectively disabling Gradle caching mechanism... I'll open a separate issue though

[hsz]

@PawelLipski That happens just during the code instrumentation task, right?

[PawelLipski]

I'm not sure, still researching... but probably not only. I've disabled the following tasks:

      buildPlugin.enabled = false
      buildSearchableOptions.enabled = false
      downloadRobotServerPlugin.enabled = false
      instrumentCode.enabled = false
      instrumentTestCode.enabled = false
      instrumentUiTestCode.enabled = false
      jarSearchableOptions.enabled = false
      patchPluginXml.enabled = false
      prepareSandbox.enabled = false
      prepareTestingSandbox.enabled = false
      prepareUiTestingSandbox.enabled = false
      publishPlugin.enabled = false
      runIde.enabled = false
      runIdeForUiTests.enabled = false
      setupInstrumentCode.enabled = false
      verifyPlugin.enabled = false

but still seeing classpath.index generated, and Gradle reporting that it doesn't know where classpath.index came from, and hence disabling caching for the affected output directory :/

[hsz]

Have you tried 1.7.0-SNAPSHOT?

[PawelLipski]

Also! as a workaround, I tried setting

  test {
    systemProperty "idea.classpath.index.enabled", "false"
  }

and/or passing ./gradlew -Didea.classpath.index.enabled=false... but to no avail. The only workaround I've found so far is to just

find . -name classpath.index -delete || true

right after running the tests ://

[PawelLipski]

Have you tried 1.7.0-SNAPSHOT?

Huh lemme check 🤔

[PawelLipski]

The same with 1.7.0-SNAPSHOT... looks that it's happening in <project>:test actually!

> Task :test
OpenJDK 64-Bit Server VM warning: Archived non-system classes are disabled because the java.system.class.loader property is specified (value = "com.intellij.util.lang.PathClassLoader"). To use archived non-system classes, this property must be not be set

Class loader is apparently set to com.intellij.util.lang.PathClassLoader in tests of modules where gradle-intellij-plugin is enabled... and this seems to lead to classpath.index showing up in build/classes/ for these modules :/

[PawelLipski]

Opened #1039, let's track it there instead