I'm working on some features that involve changes to both Lucene and Solr. Post-TLP-split, I'm wondering whether anyone has recommended techniques to handle this kind of situation.
Ideally one would work on Lucene changes, get them merged, and then proceed with Solr development; but realistically even if this were as straightforward in practice as it sounds in principal, there are cases where one would still want to develop in parallel. I haven't been able to find any documented recommendation on this subject. It's possible to have a locally built Lucene snapshot (via `gradlew mavenToLocalRepo`); but I was only able to actually _build_ Solr against the local Lucene artifact by adding `mavenLocal()` to the `allprojects/repositories` block in `gradle/defaults.gradle` -- and I have yet to figure a way get the local Lucene artifact on the test classpath (so I'm as yet unable to run Solr tests that depend on unmerged upstream changes to Lucene). It's also possible that the partially-functional approach described above will have to change now that Solr main depends on a specific Lucene snapshot version. Is anybody doing something like this? Or perhaps I'm asking the wrong question? I can think of solutions that involve setting up my own maven repository, to which I publish my own pinned versions of Lucene, and refer to such pinned versions/repo as part of a given Solr "patch". But that feels both half-baked _and_ bloated, so I don't want to go down that road unless I feel convinced there's no better alternative. Michael --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
