Hi Michael again, as a small addon: Due to the previously descibed changes, it is no longer needed to do the development in parallel (unless you want to check some compatibility or have a wider test-coverage). As Solr is now using a pinned "prerelease" (from ASF jenkins build number), you can add breaking changes to Lucene and Solr won't suddenly fail. Once you are ready to port the changes to Solr, you can trigger a new "prerelease" build on ASF jenkins and use it for development. So we are now completely decouped!
Uwe ----- Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: [email protected] > -----Original Message----- > From: Uwe Schindler <[email protected]> > Sent: Thursday, May 27, 2021 6:09 PM > To: [email protected] > Subject: RE: Solr/Lucene joint development workflow? > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
