To whomever does this first, it would be great if the steps could be written down carefully in more detail so that it can be shared for its eventual inclusion in /dev-docs
Maybe "mavenLocalI()" should simply be added to Gradle's repo list by default? This will speed up some first-time builds in some environments who already have lots of local Maven dependencies. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Thu, May 27, 2021 at 12:09 PM Uwe Schindler <[email protected]> wrote: > 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] > >
