Do we have any tests that operate on a "real" Solr instance running from
"bin/solr"? Such tests could find problems with bin/solr and any classpath
matters in how Jetty operates. Solr does have JettySolrRunner which is
great but doesn't cover the aforementioned matters.
We've got some really
Hi,
My votes (binding): A1, D
Reason: I want to keep the original Lucene colors, so A1 is the only
alternative. I still really like the old one, if it would be better vectorized,
so my second choice is D.
Uwe
-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
Hi,
> > Enforcing version and gradlew vs local shouldn't be difficult.
>
> We already enforce the version:
> https://github.com/dweiss/lucene-solr/blob/master/gradle/validation/check-
> environment.gradle#L42-L45
>
> If you run a non-wrapper gradle (local) or via gradlew does not matter
> as
re: txt files .vs. the Wiki. In the end, I came down on keeping text files
pure. I’ve come to view it as something of a hierarchy, the less the plain text
files reference this web thingy the better. So I’ll change the CWiki page to
mention the plain text files and leave it at that…
I did make
I fixed it in SOLR-14836
On Sun, Sep 6, 2020 at 9:44 AM Dawid Weiss wrote:
>
> Please file an issue.
> D.
>
> On Sun, Sep 6, 2020 at 5:02 AM Alexandre Rafalovitch
> wrote:
> >
> > It seems that solr/licenses/README.committers.txt file is not ignored
> > in the gradle build and slips into the
> > remember the goal is to split Lucene and Solr repositories...
>
> As of 9.0.0 ? :)
The build itself - absolutely. When you think about packaging source
distributions it'll be a nightmare to distribute with a top-level
wrapper, etc. This has to be split into two independent gradle root
> Enforcing version and gradlew vs local shouldn't be difficult.
We already enforce the version:
https://github.com/dweiss/lucene-solr/blob/master/gradle/validation/check-environment.gradle#L42-L45
If you run a non-wrapper gradle (local) or via gradlew does not matter
as long as it's the same
Enforcing version and gradlew vs local shouldn't be difficult. As you said,
Uwe, the version is gettable programmatically, and could be checked in the
same check-environment script Dawid already mentioned. Whether or not the
gradle wrapper is being used is a little tricker, but the code source for
Hi,
I was thinking about a check, do build refuses to start when it figures out
that Gradle version is not exactly ours or it's stated not from gradlew (I
think we have something for checking if gradlew script has all modifications).
I think this should be doable? Getting version number of
> remember the goal is to split Lucene and Solr repositories...
As of 9.0.0 ? :)
I found lucene/BUILD.md needs to be refined anyways (it contains
information for Solr devs for some reason), so I opened a PR.
https://github.com/apache/lucene-solr/pull/1835
Please review it, I'd merge it in the
I'd rather move things out of the top-level and into solr/ lucene/
folders - remember the goal is to split Lucene and Solr
repositories...
Dawid
On Sun, Sep 6, 2020 at 2:46 AM Tomoko Uchida
wrote:
>
> For what it's worth, we already have lucene/BUILD.md in the repository:
>
Please file an issue.
D.
On Sun, Sep 6, 2020 at 5:02 AM Alexandre Rafalovitch wrote:
>
> It seems that solr/licenses/README.committers.txt file is not ignored
> in the gradle build and slips into the distribution package.
>
> I did not check if this affects the 8_x branch.
>
> Do I need to
A1, D (binding)
Regards,
Munendra S N
On Fri, Sep 4, 2020 at 7:02 PM Michael Sokolov wrote:
> A1, D, A2 (binding)
>
> On Fri, Sep 4, 2020 at 12:46 AM David Smiley wrote:
> >
> > (binding)
> > vote: D, A1
> >
> >
> > (thanks Ryan for your thorough vote instructions & preparation)
>
>
13 matches
Mail list logo
