This kind of problem has happened before. Gus has noticed & fixed it in a past release, and I believe Dawid Weiss did just recently https://github.com/apache/solr/pull/4225/changes which you commented on Eric but maybe didn't realize it's the same problem you encountered with Querqy.
I filed a PR w/ Copilot to enhance the smoketest to check that a Maven project can resolve our dependencies. This includes some trivial test java code. While my objective was limited to dependencies, we can imagine generalizing it's job to not be purely limited to the dependency validation but also to check some basic things that a SolrJ & solr-test-framework consumer might do -- exercising some SolrTestCase & SolrClientTestRule stuff to ensure they are functional. I'm working on revamping it right now, including a fix for ExternalPaths. On Sat, Mar 21, 2026 at 2:37 PM David Eric Pugh via dev <[email protected]> wrote: > I was updating the https://github.com/querqy/querqy-solr repo for Solr > 10, and then tests started due to issues with ExternalPaths. > I asked claude for help and it said: > The `ExternalPaths` class assumed it was running within the Solr source > tree and attempted to resolve paths like `webapp/web`, > `server/solr/configsets/_default/conf`, etc. on the `SOURCE_HOME` path. > When `SOURCE_HOME` was `null` (as in external projects), calling > `.resolve()` on it caused an NPE. > > I dug a bit more, and it was caused when we did the File --> Path migation > in SOLR-16903 (commit 86f2afded1252b69b8478a2c795a7657585ef5c2). > In Java's `java.io.File` implementation: > ```javaFile file = new File(null, "webapp/web"); // This is LEGALString > path = file.getAbsolutePath(); // Returns a valid path > (relative)```but with path: > ```javaPath path = null;path.resolve("webapp/web"); // ❌ > NullPointerException!``` > I have a potential patch here: > https://gist.github.com/epugh/beaf36329593aa879af2d26eaa9030fd > Thoughts? Am I understanding things correctly? > Eric > >
