> Yet I feel certain I have been able to run all tests in IJ before. >
I don't think this was ever the case with intellij. Or maybe you ran those tests via gradle? > There are a few oddities that happen in intellij that require you to > fiddle with the build in odd ways, but I wonder if these will be > reproducible or if they maybe happen because there is some bad state: > Intellij changes from version to version so there is no "one" version, unfortunately. Also, sometimes some of the settings intellij sets up on the initial import persist and 'reloading' the gradle plugin does not help to update them. An occasional import from scratch is a good way to check if something like this happens. 1. Building branch_9x with intellij builder selected in the gradle > settings failed to build the benchmark module due to some modules not > being visible to it (e.g. icu). So I "unload module benchmark" > effectively skipping building that, and then I am able to build the > rest of lucene. YMMV > I can't reproduce this on main, haven't tried 9x. > 2. After switching back to main branch, I got a build failure "error: > Annotation generator had thrown the exception. > javax.annotation.processing.FilerException: Attempt to recreate a file > for type > org.apache.lucene.benchmark.jmh.jmh_generated.ExpressionsBenchmark_expression_jmhTest". > I see there are some generated classes in > lucene/benchmark_jmh/src/java/generated, that show up in git status, > so I remove that folder and then everything is fine - some cruft left > from a previous build? > This is intellij's compiler emitting annotation processor output (jmh) to an incorrect location. It's javac's '-s' option. Not sure how to configure this option so that intellij picks it up from the gradle build model. > Side note: when running all tests in "intellij" mode you cannot do it > by selecting the "core" module - you have to navigate down to the > "tests" folder. Correct, This is the classpath-container unit which contains tests. > Also I observed that when running tests in "gradle" > mode I no longer observed the slow startup times? Really unsure what > that means. Maybe some networking thing? > Or the daemon starting for the first time - this is relatively expensive. Once the daemon is up, launch times should be faster. > But the main thing I learned is that while running tests using > intellij builder mostly works, MemorySegmentIndexInputProvider fails > to get loaded and any test using MMapDirectory will fail, regardless > of whether I run a single test or a whole suite. This is true on both > 9x and main branches and causes 1/3-1/2 of tests to fail in core. > This class is in src/java21 - it's not picked up as a source folder by intellij. And if you add it manually, you'll get errors related to compilation because of the way the gradle build "cheats" javac and bypasses explicitly importing jdk.incubator.vector and not declaring --enable-preview... In short: yes, it'll be difficult to work around that, especially with an automatic project import in intellij (perhaps you could hand-craft configuration files so that it works, I'm not sure). > At this point I'm reluctant to recommend using the intellij build > mode. Maybe it will become viable again if we can figure out how to > get MMapDirectory tests to work with it? > I use it because it's much faster. Whenever I need something more complex, I set up a dedicated gradle launch configuration for that - like so: [image: image.png] I'm neither gradle nor intellij expert though, it's mostly a trial-and-error of what works and what doesn't... D.
