D (binding).
On Tue, Sep 1, 2020 at 5:56 AM Ryan Ernst wrote:
>
> Dear Lucene and Solr developers!
>
> In February a contest was started to design a new logo for Lucene
> [jira-issue]. The initial attempt [first-vote] to call a vote resulted in
> some confusion on the rules, as well the
I did not say it was trivial, but I also did not quite mention the previous
research.
https://github.com/arafalov/solr-refguide-indexing/blob/master/src/com/solrstart/refguide/Indexer.java
Uses official AsciidoctorJ library directory. Not sure if that's just JRuby
version of Asciidoctor we
Some background to consider before committing to that... it might not be as
trivial as you think. (I've often thought it ironic that we don't have real
search for our ref guide... )
https://www.youtube.com/watch?v=DixlnxAk08s
-Gus
On Mon, Aug 31, 2020 at 2:06 PM Ishan Chattopadhyaya <
A2
On Tue, 1 Sep 2020, 4:26 am Ryan Ernst, wrote:
> Dear Lucene and Solr developers!
>
> In February a contest was started to design a new logo for Lucene
> [jira-issue]. The initial attempt [first-vote] to call a vote resulted in
> some confusion on the rules, as well the request for one
Dear Lucene and Solr developers!
In February a contest was started to design a new logo for Lucene
[jira-issue]. The initial attempt [first-vote] to call a vote resulted in
some confusion on the rules, as well the request for one additional
submission. I would like to call a new vote, now with
Excellent, I’ve put it in my notes… you get a lot of entries there… Thanks!
> On Aug 31, 2020, at 2:59 PM, Dawid Weiss wrote:
>
>> Is there an easy way to insure that versions.props only has necessary
>> dependencies listed? Ideally it would be just a top-level command.
>
> If a dependency
It was causing issues when I was building solr start resource website too.
So +1 on sorting it out.
Regards,
Alex.
On Mon., Aug. 31, 2020, 5:50 p.m. Tomoko Uchida, <
tomoko.uchida.1...@gmail.com> wrote:
> Hello devs,
>
> we have lots of package name conflicts (shared package names) between
Hello devs,
we have lots of package name conflicts (shared package names) between
modules in the Lucene/Solr source tree. It is not only annoying for
devs/users but also indeed bad practice since Java 9 (according to my
understanding), and we already have some problems with Javadocs due to
these
Also I think that discussion around the use of a feature should take place
on the user list, instead of the dev list. Users are the intended audience
for that kind of question.
- Houston
On Mon, Aug 31, 2020 at 5:21 PM Houston Putman
wrote:
> Thanks for bringing this up David.
>
> To start, I
Thanks for bringing this up David.
To start, I definitely agree that removal of contribs should have a
discussion, then a vote before any action is taken.
There have been a few bug fixes/improvements made this year, but there has
not been a lot of development on it.
If there is little use of the
I'd prefer discussion about removal of contribs (or major parts of Solr)
occur here first with a vote, and _then_ file a JIRA if the conclusion is
to remove it. It's more visible to each other and the community.
~ David Smiley
Apache Lucene/Solr Search Developer
+1, please open a jira and I'll take care of it.
Fyi, Marcus is helping me with migrating contrib modules to first party
package, and this was on our radar. I am totally occupied in other things
lately and hence slowed down on that effort. Will pick up pace end of this
week.
On Tue, 1 Sep, 2020,
Our new package system allows for a viable/healthy ecosystem of 3rd party
packages that are easy to find & install. I wonder if the Analytics
contrib module should be 3rd party? I suspect it is very rarely used,
especially with the relative strength and growth of Solr's built-in JSON
facet
> Is there an easy way to insure that versions.props only has necessary
> dependencies listed? Ideally it would be just a top-level command.
If a dependency isn't used, check will fail. It's a feature of
palantir's version control plugin. The concrete task that does it is
named
Hmmm, that’s kind of an dilemma then. Are you saying that
he test can see that the directory appears writable then tries
to write to it then gets tripped up by the framework?
Seems to me that a test that tries to write, thinks it can and then
can’t should fail anyway.
Well, I don’t think there
I love the idea of making the ref guide itself as an example dataset. That
way, we won't need to ship anything separately. Python's beautiful soup can
extract text from the html pages. I'm sure there maybe such things in Java
too (can Tika do this?).
On Mon, 31 Aug, 2020, 11:18 pm Alexandre
Hi,
I need a sanity check.
I am in the planning stages for the new example datasets to ship with
Solr 9. The one I am looking at is great for structured information,
but is quite light on full-text content. So, I am thinking of how
important that is and what other sources could be used.
One -
Some tests "create" a new solr home dir and copy config files there, but
you'll see this type of WARN logging for any test that just uses the test
configs "in place" because of how the code is designed to _try_ and create
a userfiles directory in the solr home if it's writable.
: Date: Sat,
Is there an easy way to insure that versions.props only has necessary
dependencies listed? Ideally it would be just a top-level command.
I got to wondering about this thinking about all the code that’s being removed
from core and was wondering how we’d be sure that any dependencies that were
Hi Robert,
please revert this and open an issue. There was a discussion about this and
commits like this should not be done without negotiation.
Uwe
-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From:
20 matches
Mail list logo
