lucene-dev-repo-composite.gradle

[Gus Heck <gu...@gmail.com>]

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)

Re: lucene-dev-repo-composite.gradle

[Michael Gibney <mi...@michaelgibney.net>]

`-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 <gu...@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-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org