> > 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?
When I say "run in IJ" I mean I right clicked a button somewhere and said "run all tests" :) I expect it was with the gradle runner selected. On Mon, Jun 10, 2024 at 6:38 AM Dawid Weiss <dawid.we...@gmail.com> wrote: > > 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. >
