> Having that explicitly called out would have been SUPER helpful.
Blaming Java in an exception thrown by Lucene is a ridiculous idea.
On Wed, 17 May, 2023, 3:33 am Gus Heck, wrote:
> Found it.
>
> It's a solr thing made worse by the interaction of lucene testutils and
> jdk.internal.loader.URL
Found it.
It's a solr thing made worse by the interaction of lucene testutils and
jdk.internal.loader.URLClassPath's decision to hide anything gone wrong
when checking a URL
/*
* Checks whether the resource URL should be returned.
* Returns null on security check failure.
* Call
I agree Ishan,
just wanted to mention what I can donate from my company anyway.
Happy to allow a customized logo and colors for the Solr section and allow
a redirect from solr.apache.org/discussions it that's something useful.
Cheers
--
*Alessandro Benedetti*
Director @ Seas
I would prefer if this discussion forum is hosted at an official domain,
e.g. solr.apache.org/discussions or something like that. That's the only
right way to support an official solution.
Can ASF help us here in any way?
On Tue, 16 May, 2023, 2:09 pm Alessandro Benedetti,
wrote:
> We have been
`-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
We have been working for the last few months on an upcoming Information
Retrieval forum: https://ir-relevant.net
This will be a fully free forum, sponsored by my company.
We have an Apache Solr section:
https://ir-relevant.net/forums/forum/search-technologies/apache-solr/, and
I would be happy to
