Hi Michael, since yesterday, the Lucene dependency is no longer a snapshot one, so parts of your mail are no longer valid. But the worksflow is very similar.
If the Solr team wants to use a newer preview build of Lucene, there is a workflow using ASF Jenkins that can build a new "prerelease" release of the Lucene main branch and deploy it on some ASF data dump server as maven repository. The Gradle build of Solr is referring to the recent repository and picks a specific version (the build number of ASF jenkins). For joint development, I'd suggest to work like this: - Change the dependency in the gradle versions.props file to SNAPSHOT (only local, don't submit this as PR) - Add mavenLocal() as suggested in your mail (only local, don't submit this as PR) - develop changes in lucene and install them in local repo - use them from solr through the snapshot dependency. BUT: make sure the snapshot is updated, this can be enforced by passing a gradlew command line parameter to redownload all dependencies. - once you are done with joint development create pull requests in both repositories - Lucene's change should be merged first. Once this is done and all tests pass, ask a committer to trigger the Jenkins job to build a new prerelease - Update the Solr pull request and enter the new repository coordinates created by Jenkins (needs to be done in 2 files, see below). For more details how to update Lucene dependencies in Solr, run: $ gradlew :helpDeps Uwe ----- Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: [email protected] > -----Original Message----- > From: Michael Gibney <[email protected]> > Sent: Wednesday, May 26, 2021 8:02 PM > To: [email protected] > Subject: Solr/Lucene joint development workflow? > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
