`-Plucene.dev.path=[path]` in particular can be useful for iterative development of Lucene as used in the context of Solr, or as cross-checked through Solr tests.
IIRC I've found that the versions.props/lock bypasses mavenLocal and always tries to re-download dependencies? Jar checksums might also be an issue (I forget how it's determined when jar checksums are necessary). Generally the `-Plucene.dev.*` approaches are just convenience -- I'm sure there are other ways to achieve nearly the same result. But I remember concluding that achieving the same result would require running an actual maven server (like, http). Developing with `-Plucene.dev.path` provides quite a good experience (esp. given the gradle support in IntelliJ/Idea), with up-to-date stack traces to editable Lucene code, etc. I'm definitely curious to hear more about your experience, whether you pursue the `-Plucene.dev.*` approach or the `versions.props/locl` approach, and I'm happy to help take a look at making error messages more helpful. Michael On Mon, May 15, 2023 at 11:32 AM Gus Heck <gus.h...@gmail.com> wrote: > > This file starts with the following comment; > > // Local Lucene development repository resolution: > // 1) A "-Plucene.dev.version=[version]" property, resolving Lucene > artifacts from a local Maven repository. > // 2) A non-empty property "-Plucene.dev.path=[path]" pointing to a local > path. Relative paths > // are resolved against the root project directory. > // 3) An auto-wired 'lucene' subfolder, if present. To skip auto-wiring, > pass > // a blank value in step 2: "-Plucene.dev.path=". > > But it's not clear to me if these are supposed to be alternatives, or if > all are supposed to be required. And I notice that further down it's > talking about versions.props but if I've updated that to match version on > the jar file, do I need any of this? > > My normal method for developing a library (of any sort) is to deploy to > mavenLocal()... and then load from there.... Once that's done (and version > lock updated etc, which was easier to find than this file because of error > messages) it should "just work" I would expect. > > -- > http://www.needhamsoftware.com (work) > http://www.the111shift.com (play) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
