[jira] [Commented] (SOLR-16825) Generate Java bindings from OpenAPI spec
[
https://issues.apache.org/jira/browse/SOLR-16825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17912254#comment-17912254
]
Ishan Chattopadhyaya commented on SOLR-16825:
-
This commit might be responsible for a broken Eclipse build on branch_9x. Once
{{./gradlew eclipse}} generates a project, the project can be opened in
Eclipse. However, all these mustache generated files are not found in the
Eclipse project. As a result, compilation errors occur and I don't know how to
proceed further.
If this can't be fixed, we need to stop advertising support for Eclipse. :-(
> Generate Java bindings from OpenAPI spec
>
>
> Key: SOLR-16825
> URL: https://issues.apache.org/jira/browse/SOLR-16825
> Project: Solr
> Issue Type: Improvement
> Components: v2 API
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Major
> Labels: pull-request-available
> Fix For: 9.8
>
> Time Spent: 13h 50m
> Remaining Estimate: 0h
>
> SOLR-16346 added support to Solr's build to generate an "OpenAPI spec" file
> describing our v2 API. But currently, this spec file isn't actually used by
> Solr in any way.
> Spec files can be used for a variety of purposes, including to [generate
> client bindings|https://github.com/OpenAPITools/openapi-generator] for using
> the API.
> The client generation capabilities provided by the OpenAPI project cover a
> variety of languages, but it make sense for Solr to start with Java since we
> already have a Java client that requires continual effort to keep up to date.
> It'd be a big win for the project if we were able to replace some or all of
> the manually maintained "SolrRequest" implementations in SolrJ with
> automatically generated code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] Move DOMUtil ConfigNode methods to ConfigNode, with some name changes. [solr]
epugh commented on code in PR #3027:
URL: https://github.com/apache/solr/pull/3027#discussion_r1912458457
##
solr/core/src/java/org/apache/solr/core/PluginInfo.java:
##
@@ -100,39 +100,23 @@ public String toString() {
}
}
+ /** From XML. */
Review Comment:
Maybe extend just a bit? From schema.xml? It made me look for a similar
constructor that was `/** From JSON. */` further down...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17221) Http2SolrClient merges case sensitive solr params
[
https://issues.apache.org/jira/browse/SOLR-17221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17221:
--
Labels: pull-request-available (was: )
> Http2SolrClient merges case sensitive solr params
> -
>
> Key: SOLR-17221
> URL: https://issues.apache.org/jira/browse/SOLR-17221
> Project: Solr
> Issue Type: Bug
> Components: SolrJ
>Affects Versions: 9.5
>Reporter: Yue Yu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In solr9.5.0/solrj9.5.0, the multi-shard requests are sent through
> Http2SolrClient, and this function composes the actual Jetty Request object:
> {code:java}
> private Request fillContentStream(
> Request req,
> Collection streams,
> ModifiableSolrParams wparams,
> boolean isMultipart)
> throws IOException {
> if (isMultipart) {
> // multipart/form-data
> try (MultiPartRequestContent content = new MultiPartRequestContent()) {
> Iterator iter = wparams.getParameterNamesIterator();
> while (iter.hasNext()) {
> String key = iter.next();
> String[] vals = wparams.getParams(key);
> if (vals != null) {
> for (String val : vals) {
> content.addFieldPart(key, new StringRequestContent(val), null);
> }
> }
> }
> if (streams != null) {
> for (ContentStream contentStream : streams) {
> String contentType = contentStream.getContentType();
> if (contentType == null) {
> contentType = "multipart/form-data"; // default
> }
> String name = contentStream.getName();
> if (name == null) {
> name = "";
> }
> HttpFields.Mutable fields = HttpFields.build(1);
> fields.add(HttpHeader.CONTENT_TYPE, contentType);
> content.addFilePart(
> name,
> contentStream.getName(),
> new InputStreamRequestContent(contentStream.getStream()),
> fields);
> }
> }
> req.body(content);
> }
> } else {
> // application/x-www-form-urlencoded
> Fields fields = new Fields();
> Iterator iter = wparams.getParameterNamesIterator();
> while (iter.hasNext()) {
> String key = iter.next();
> String[] vals = wparams.getParams(key);
> if (vals != null) {
> for (String val : vals) {
> fields.add(key, val);
> }
> }
> }
> req.body(new FormRequestContent(fields, FALLBACK_CHARSET));
> }
> return req;
> } {code}
> The problem is the use of this class *Fields fields = new Fields();* where
> caseSensitive=false by default, this leads to case sensitive solr params
> being merged together. For example f.case_sensitive_field.facet.limit=5 &
> f.CASE_SENSITIVE_FIELD.facet.limit=99
> Not sure if this is intentional for some reason?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[PR] SOLR-17221: Http2SolrClient merges case sensitive solr params [solr]
831973741yy opened a new pull request, #3028: URL: https://github.com/apache/solr/pull/3028 https://issues.apache.org/jira/browse/SOLR-17221 # Description The Request object composed by Http2SolrClient via POST/PUT method merges case sensitive solr params. This is because it uses the default constructor of the Fields class (org/eclipse/jetty/util/Fields.java) which sets caseSensitive=false # Solution Set caseSensitive=true when instantiate Fields object # Tests Added unit tests to cover case sensitive solr param cases, even for other methods such as GET, etc # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://github.com/apache/solr/blob/main/CONTRIBUTING.md) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended, not available for branches on forks living under an organisation) - [x] I have developed this patch against the `main` branch. - [x] I have run `./gradlew check`. - [x] I have added tests for my changes. - [ ] I have added documentation for the [Reference Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17406) Introduce Gradle Version Catalogs
[
https://issues.apache.org/jira/browse/SOLR-17406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17912283#comment-17912283
]
Ishan Chattopadhyaya commented on SOLR-17406:
-
This issue removed Eclipse IDE support without any discussion around it.
./gradlew tasks after this commit:
{code}
IDE tasks
-
cleanIdea - Cleans IDEA project files (IML, IPR)
idea - Generates IDEA project files (IML, IPR, IWS)
openIdea - Opens the IDEA project
{code}
the same before this commit:
{code}
IDE tasks
-
cleanEclipse - Cleans all Eclipse files.
cleanIdea - Cleans IDEA project files (IML, IPR)
eclipse - Generates all Eclipse files.
idea - Generates IDEA project files (IML, IPR, IWS)
openIdea - Opens the IDEA project
{code}
Such things happening without due discussion is very annoying.
> Introduce Gradle Version Catalogs
> -
>
> Key: SOLR-17406
> URL: https://issues.apache.org/jira/browse/SOLR-17406
> Project: Solr
> Issue Type: Improvement
> Components: Gradle
>Affects Versions: main (10.0)
>Reporter: Christos Malliaridis
>Assignee: Christos Malliaridis
>Priority: Minor
> Labels: dependencies, gradle, pull-request-available
> Time Spent: 8h
> Remaining Estimate: 0h
>
> With Gradle it is possible to manage versions and dependencies in gradle
> files via version catalogs. This allows us to cleanup dependency resolution
> and move various versions from across the project to a single file.
> Dawid Weiss demonstrated in [Lucene PR
> #13484|https://github.com/apache/lucene/pull/13484/] such a migration
> together with a few improvements in the gradle build files that could be
> addressed in this ticket aswell.
> The migration include the removal of palantir's consistent versions plugin.
> Dev list thread:
> [https://lists.apache.org/thread/wh6c0x2ncbpd61pwwddtv3l256lv9kr5]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17406) Introduce Gradle Version Catalogs
[ https://issues.apache.org/jira/browse/SOLR-17406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17912285#comment-17912285 ] Ishan Chattopadhyaya commented on SOLR-17406: - [~malliaridis] , simple reverting the changes in gradle/ide/eclipse.gradle didn't work. :( Any ideas, please? > Introduce Gradle Version Catalogs > - > > Key: SOLR-17406 > URL: https://issues.apache.org/jira/browse/SOLR-17406 > Project: Solr > Issue Type: Improvement > Components: Gradle >Affects Versions: main (10.0) >Reporter: Christos Malliaridis >Assignee: Christos Malliaridis >Priority: Minor > Labels: dependencies, gradle, pull-request-available > Time Spent: 8h > Remaining Estimate: 0h > > With Gradle it is possible to manage versions and dependencies in gradle > files via version catalogs. This allows us to cleanup dependency resolution > and move various versions from across the project to a single file. > Dawid Weiss demonstrated in [Lucene PR > #13484|https://github.com/apache/lucene/pull/13484/] such a migration > together with a few improvements in the gradle build files that could be > addressed in this ticket aswell. > The migration include the removal of palantir's consistent versions plugin. > Dev list thread: > [https://lists.apache.org/thread/wh6c0x2ncbpd61pwwddtv3l256lv9kr5] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17406) Introduce Gradle Version Catalogs
[
https://issues.apache.org/jira/browse/SOLR-17406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17912284#comment-17912284
]
Ishan Chattopadhyaya commented on SOLR-17406:
-
As I re-read Christos' comment in dev@ list, this may have happened
inadvertently.
I'm looking at the fix, based on his suggestion:
{quote}
Could you check if reverting the "wrapping" (line 24 in
gradle/ide/eclipse.gradle) of the eclipse-related part resolves the issue?
See the changes in eclipse.gradle from
https://github.com/apache/solr/commit/c9d3885f2fd0a7edf5efe4a264d0bdc276109eba
{quote}
> Introduce Gradle Version Catalogs
> -
>
> Key: SOLR-17406
> URL: https://issues.apache.org/jira/browse/SOLR-17406
> Project: Solr
> Issue Type: Improvement
> Components: Gradle
>Affects Versions: main (10.0)
>Reporter: Christos Malliaridis
>Assignee: Christos Malliaridis
>Priority: Minor
> Labels: dependencies, gradle, pull-request-available
> Time Spent: 8h
> Remaining Estimate: 0h
>
> With Gradle it is possible to manage versions and dependencies in gradle
> files via version catalogs. This allows us to cleanup dependency resolution
> and move various versions from across the project to a single file.
> Dawid Weiss demonstrated in [Lucene PR
> #13484|https://github.com/apache/lucene/pull/13484/] such a migration
> together with a few improvements in the gradle build files that could be
> addressed in this ticket aswell.
> The migration include the removal of palantir's consistent versions plugin.
> Dev list thread:
> [https://lists.apache.org/thread/wh6c0x2ncbpd61pwwddtv3l256lv9kr5]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] Payload Score Parser: expand documentation's pointing to Lucene javadocs [solr]
epugh commented on PR #2693: URL: https://github.com/apache/solr/pull/2693#issuecomment-2585747352 GOing to take one more stab at this one... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17618: Add unit tests for org.apache.solr.util.TimeOut [solr]
madrob commented on code in PR #3026:
URL: https://github.com/apache/solr/pull/3026#discussion_r1912473651
##
solr/core/src/test/org/apache/solr/util/TimeOutTest.java:
##
@@ -0,0 +1,65 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.util;
+
+import static java.util.concurrent.TimeUnit.NANOSECONDS;
+import static org.mockito.Mockito.mock;
+import static org.mockito.Mockito.when;
+
+import org.apache.solr.SolrTestCaseJ4;
+import org.apache.solr.common.util.TimeSource;
+import org.junit.BeforeClass;
+
+public class TimeOutTest extends SolrTestCaseJ4 {
+
+ @BeforeClass
+ public static void setUpOnce() {
+assumeWorkingMockito();
+ }
+
+ public void testHasTimedOut() {
+TimeSource mockTimeSource = mock(TimeSource.class);
Review Comment:
This could go in a Before method
##
solr/core/src/test/org/apache/solr/util/TimeOutTest.java:
##
@@ -0,0 +1,65 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.util;
+
+import static java.util.concurrent.TimeUnit.NANOSECONDS;
+import static org.mockito.Mockito.mock;
+import static org.mockito.Mockito.when;
+
+import org.apache.solr.SolrTestCaseJ4;
+import org.apache.solr.common.util.TimeSource;
+import org.junit.BeforeClass;
+
+public class TimeOutTest extends SolrTestCaseJ4 {
+
+ @BeforeClass
+ public static void setUpOnce() {
+assumeWorkingMockito();
+ }
+
+ public void testHasTimedOut() {
Review Comment:
Does this need Test annotations
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17221) Http2SolrClient merges case sensitive solr params
[
https://issues.apache.org/jira/browse/SOLR-17221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17912281#comment-17912281
]
Yue Yu commented on SOLR-17221:
---
[~dsmiley] sure thing! here is the PR:
[https://github.com/apache/solr/pull/3028]
I added some more unit tests to check the case sensitive solr param case
> Http2SolrClient merges case sensitive solr params
> -
>
> Key: SOLR-17221
> URL: https://issues.apache.org/jira/browse/SOLR-17221
> Project: Solr
> Issue Type: Bug
> Components: SolrJ
>Affects Versions: 9.5
>Reporter: Yue Yu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In solr9.5.0/solrj9.5.0, the multi-shard requests are sent through
> Http2SolrClient, and this function composes the actual Jetty Request object:
> {code:java}
> private Request fillContentStream(
> Request req,
> Collection streams,
> ModifiableSolrParams wparams,
> boolean isMultipart)
> throws IOException {
> if (isMultipart) {
> // multipart/form-data
> try (MultiPartRequestContent content = new MultiPartRequestContent()) {
> Iterator iter = wparams.getParameterNamesIterator();
> while (iter.hasNext()) {
> String key = iter.next();
> String[] vals = wparams.getParams(key);
> if (vals != null) {
> for (String val : vals) {
> content.addFieldPart(key, new StringRequestContent(val), null);
> }
> }
> }
> if (streams != null) {
> for (ContentStream contentStream : streams) {
> String contentType = contentStream.getContentType();
> if (contentType == null) {
> contentType = "multipart/form-data"; // default
> }
> String name = contentStream.getName();
> if (name == null) {
> name = "";
> }
> HttpFields.Mutable fields = HttpFields.build(1);
> fields.add(HttpHeader.CONTENT_TYPE, contentType);
> content.addFilePart(
> name,
> contentStream.getName(),
> new InputStreamRequestContent(contentStream.getStream()),
> fields);
> }
> }
> req.body(content);
> }
> } else {
> // application/x-www-form-urlencoded
> Fields fields = new Fields();
> Iterator iter = wparams.getParameterNamesIterator();
> while (iter.hasNext()) {
> String key = iter.next();
> String[] vals = wparams.getParams(key);
> if (vals != null) {
> for (String val : vals) {
> fields.add(key, val);
> }
> }
> }
> req.body(new FormRequestContent(fields, FALLBACK_CHARSET));
> }
> return req;
> } {code}
> The problem is the use of this class *Fields fields = new Fields();* where
> caseSensitive=false by default, this leads to case sensitive solr params
> being merged together. For example f.case_sensitive_field.facet.limit=5 &
> f.CASE_SENSITIVE_FIELD.facet.limit=99
> Not sure if this is intentional for some reason?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] Move DOMUtil ConfigNode methods to ConfigNode, with some name changes. [solr]
epugh commented on code in PR #3027:
URL: https://github.com/apache/solr/pull/3027#discussion_r1912457832
##
solr/solrj/src/java/org/apache/solr/common/ConfigNode.java:
##
@@ -93,9 +107,16 @@ default String attr(String name) {
return attributes().get(name);
}
- default String requiredStrAttr(String name, Supplier err) {
+ /**
+ * Like {@link #attr(String)} but throws an error (incorporating {@code
missing_err}) if not
+ * found.
+ */
+ default String attrRequired(String name, String missing_err) {
Review Comment:
nit pick, but should this bee `missingErr`? Thanks for the docs..
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] Move DOMUtil ConfigNode methods to ConfigNode, with some name changes. [solr]
epugh commented on code in PR #3027:
URL: https://github.com/apache/solr/pull/3027#discussion_r1912458457
##
solr/core/src/java/org/apache/solr/core/PluginInfo.java:
##
@@ -100,39 +100,23 @@ public String toString() {
}
}
+ /** From XML. */
Review Comment:
Maybe extend just a bit? From schema.xml? It made me look for a similar
constructor that was /** From JSON. */ further down...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17618: Add unit tests for org.apache.solr.util.TimeOut [solr]
sandbergja commented on code in PR #3026:
URL: https://github.com/apache/solr/pull/3026#discussion_r1912501591
##
solr/core/src/test/org/apache/solr/util/TimeOutTest.java:
##
@@ -0,0 +1,65 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.util;
+
+import static java.util.concurrent.TimeUnit.NANOSECONDS;
+import static org.mockito.Mockito.mock;
+import static org.mockito.Mockito.when;
+
+import org.apache.solr.SolrTestCaseJ4;
+import org.apache.solr.common.util.TimeSource;
+import org.junit.BeforeClass;
+
+public class TimeOutTest extends SolrTestCaseJ4 {
+
+ @BeforeClass
+ public static void setUpOnce() {
+assumeWorkingMockito();
+ }
+
+ public void testHasTimedOut() {
+TimeSource mockTimeSource = mock(TimeSource.class);
Review Comment:
Okay! I think I get it now. Thanks for working with me on this @madrob !
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17618: Add unit tests for org.apache.solr.util.TimeOut [solr]
madrob commented on code in PR #3026:
URL: https://github.com/apache/solr/pull/3026#discussion_r1912499016
##
solr/core/src/test/org/apache/solr/util/TimeOutTest.java:
##
@@ -0,0 +1,65 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.util;
+
+import static java.util.concurrent.TimeUnit.NANOSECONDS;
+import static org.mockito.Mockito.mock;
+import static org.mockito.Mockito.when;
+
+import org.apache.solr.SolrTestCaseJ4;
+import org.apache.solr.common.util.TimeSource;
+import org.junit.BeforeClass;
+
+public class TimeOutTest extends SolrTestCaseJ4 {
+
+ @BeforeClass
+ public static void setUpOnce() {
+assumeWorkingMockito();
+ }
+
+ public void testHasTimedOut() {
+TimeSource mockTimeSource = mock(TimeSource.class);
Review Comment:
I would do Before, not BeforeClass for it, and also put the when/thenReturn
line in there as well.
Then in the tests adjust the timeouts to test various combinations if we
have the same mock time source each time. Does that make sense?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17618: Add unit tests for org.apache.solr.util.TimeOut [solr]
sandbergja commented on code in PR #3026:
URL: https://github.com/apache/solr/pull/3026#discussion_r1912491090
##
solr/core/src/test/org/apache/solr/util/TimeOutTest.java:
##
@@ -0,0 +1,65 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.util;
+
+import static java.util.concurrent.TimeUnit.NANOSECONDS;
+import static org.mockito.Mockito.mock;
+import static org.mockito.Mockito.when;
+
+import org.apache.solr.SolrTestCaseJ4;
+import org.apache.solr.common.util.TimeSource;
+import org.junit.BeforeClass;
+
+public class TimeOutTest extends SolrTestCaseJ4 {
+
+ @BeforeClass
+ public static void setUpOnce() {
+assumeWorkingMockito();
+ }
+
+ public void testHasTimedOut() {
+TimeSource mockTimeSource = mock(TimeSource.class);
Review Comment:
Ooh, good point! Thanks, @madrob !
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17618: Add unit tests for org.apache.solr.util.TimeOut [solr]
sandbergja commented on code in PR #3026:
URL: https://github.com/apache/solr/pull/3026#discussion_r1912491073
##
solr/core/src/test/org/apache/solr/util/TimeOutTest.java:
##
@@ -0,0 +1,65 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.util;
+
+import static java.util.concurrent.TimeUnit.NANOSECONDS;
+import static org.mockito.Mockito.mock;
+import static org.mockito.Mockito.when;
+
+import org.apache.solr.SolrTestCaseJ4;
+import org.apache.solr.common.util.TimeSource;
+import org.junit.BeforeClass;
+
+public class TimeOutTest extends SolrTestCaseJ4 {
+
+ @BeforeClass
+ public static void setUpOnce() {
+assumeWorkingMockito();
+ }
+
+ public void testHasTimedOut() {
Review Comment:
Thanks, I was wondering about that!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17221: Http2SolrClient merges case sensitive solr params [solr]
831973741yy commented on code in PR #3028:
URL: https://github.com/apache/solr/pull/3028#discussion_r1912637510
##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/Http2SolrClient.java:
##
@@ -784,7 +784,7 @@ private Request fillContentStream(
}
} else {
// application/x-www-form-urlencoded
- Fields fields = new Fields();
+ Fields fields = new Fields(true);
Iterator iter = wparams.getParameterNamesIterator();
while (iter.hasNext()) {
Review Comment:
yep, the logic in this else block + convert function in FormRequestContent
is largely the same as wparams.toQueryString() except:
- leading question mark from wparams.toQueryString()
- wparams.toQueryString() uses hard coded utf-8 charset as oppose to the
FALLBACK_CHARSET passed to FormRequestContent
I guess we can replace it (I tried it, and all unit tests passed), but we
need to
1. put in some logic (if wparams.toQueryString().startwith("?") then
wparams.toQueryString().substring(1)) to handle the leading question mark from
wparams.toQueryString(). Although not likely, if the toQueryString function
changes the question mark logic in the future, we might have problem here.
2. assume FALLBACK_CHARSET remains utf-8 or pass a charset to
SolrParams.toQueryString function (not sure if adding a new toQueryString
function in SolrParams is justified for this special use case)
The current implementation with Fields has less dependencies stated above
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17221: Http2SolrClient merges case sensitive solr params [solr]
dsmiley commented on code in PR #3028:
URL: https://github.com/apache/solr/pull/3028#discussion_r1912650870
##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/Http2SolrClient.java:
##
@@ -784,7 +784,7 @@ private Request fillContentStream(
}
} else {
// application/x-www-form-urlencoded
- Fields fields = new Fields();
+ Fields fields = new Fields(true);
Iterator iter = wparams.getParameterNamesIterator();
while (iter.hasNext()) {
Review Comment:
The current code here is longer and goes through a Fields intermediary
mapping. This is why I find SolrParams existing method toQueryString a
tempting substitute. I'm doubtful we'll change toQueryString's leading
question mark because it's not worth the disturbance on users for a triviality.
I think FALLBACK_CHARSET must be UTF8 always be design. It's not clear what
purpose this constant serves vs referencing UTF8 directly.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] Remove ingress and node-services during reconcile [solr-operator]
HoustonPutman commented on PR #674: URL: https://github.com/apache/solr-operator/pull/674#issuecomment-2586143084 Yes, we should definitely include this. I'll try to get it merged early this week -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] Move DOMUtil ConfigNode methods to ConfigNode, with some name changes. [solr]
dsmiley commented on code in PR #3027:
URL: https://github.com/apache/solr/pull/3027#discussion_r1912653511
##
solr/solrj/src/java/org/apache/solr/common/ConfigNode.java:
##
@@ -93,9 +107,16 @@ default String attr(String name) {
return attributes().get(name);
}
- default String requiredStrAttr(String name, Supplier err) {
+ /**
+ * Like {@link #attr(String)} but throws an error (incorporating {@code
missing_err}) if not
+ * found.
+ */
+ default String attrRequired(String name, String missing_err) {
Review Comment:
Not my naming choice; I can rename
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] Move DOMUtil ConfigNode methods to ConfigNode, with some name changes. [solr]
dsmiley commented on code in PR #3027:
URL: https://github.com/apache/solr/pull/3027#discussion_r1912653422
##
solr/core/src/java/org/apache/solr/core/PluginInfo.java:
##
@@ -100,39 +100,23 @@ public String toString() {
}
}
+ /** From XML. */
Review Comment:
This constructor supports XML config generally; not just a specific file as
you wondered. I added it because it may not be obvious to the reader who may
be unfamiliar with `ConfigNode` but who would recognize XML `Node` type. The
other constructors are more general; can't be said to be from any particular
format. I could drop this but was trying to be helpful.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17221: Http2SolrClient merges case sensitive solr params [solr]
831973741yy commented on PR #3028: URL: https://github.com/apache/solr/pull/3028#issuecomment-2586024118 @dsmiley > Can you propose a short description that shall go in CHANGES.txt ? Basically, how might a user experience this bug? Case sensitive solr params does not work reliably in multi-shard setting. For example, faceting per field params such as f.CASE_SENSITIVE_FIELD.facet.limit=50. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17221: Http2SolrClient merges case sensitive solr params [solr]
831973741yy commented on code in PR #3028: URL: https://github.com/apache/solr/pull/3028#discussion_r1912584876 ## solr/solrj/src/test/org/apache/solr/client/solrj/impl/HttpSolrClientTestBase.java: ## Review Comment: correct. The other two prepare the requests that go through the flow. The case sensitive params are added there -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17406) Introduce Gradle Version Catalogs
[ https://issues.apache.org/jira/browse/SOLR-17406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17912314#comment-17912314 ] Christos Malliaridis commented on SOLR-17406: - [~ichattopadhyaya] so I had a look into this and because I never used Eclipse before, I am not sure how the project is supposed to look like. I am also not sure how a typical gradle project is supposed to be opened / imported, so I tried the following two approaches: Approach 1 - Using "gradlew eclipse": # Before opening project in Eclipse, run ./gradlew eclipse (works only on 9.x branches) # Open Eclipse, then go to File -> Open Projects from File System -> Select solr project where gradlew eclipse was executed This approach resulted in the following view: !Screenshot 2025-01-13 012825.png|width=106,height=235! Aproach 2 - Using "Eclipse Gradle (buildship) tooling" (see [https://www.vogella.com/tutorials/EclipseGradle/article.html)]: # Open Eclipse and go to File -> Import... # Under Gradle select "Existing Gradle Project" # Select the project root directory # Continue with Next until Eclipse starts analyzing the project # After it identifies the Solr project, click finish This approach works with main (clean checkout) as well and it also identifies correctly the gradle tasks without even building the project. The result would look like this: !Screenshot 2025-01-13 014721.png|width=262,height=194!!Screenshot 2025-01-13 014818.png|width=136,height=197! If the latter approach is sufficient and developers can work with that, we can probably remove gradle/ide/eclipse.gradle and update our documentation to only use the IDE features, instead of relying on a gradle plugin. P.S. I had to run "gradlew dev" once from terminal, because it was for some reason failing on solrj spotless stuff when I tried to execute the same gradle task fromt he tasks window. > Introduce Gradle Version Catalogs > - > > Key: SOLR-17406 > URL: https://issues.apache.org/jira/browse/SOLR-17406 > Project: Solr > Issue Type: Improvement > Components: Gradle >Affects Versions: main (10.0) >Reporter: Christos Malliaridis >Assignee: Christos Malliaridis >Priority: Minor > Labels: dependencies, gradle, pull-request-available > Attachments: Screenshot 2025-01-13 012825.png, Screenshot 2025-01-13 > 014721.png, Screenshot 2025-01-13 014818.png > > Time Spent: 8h > Remaining Estimate: 0h > > With Gradle it is possible to manage versions and dependencies in gradle > files via version catalogs. This allows us to cleanup dependency resolution > and move various versions from across the project to a single file. > Dawid Weiss demonstrated in [Lucene PR > #13484|https://github.com/apache/lucene/pull/13484/] such a migration > together with a few improvements in the gradle build files that could be > addressed in this ticket aswell. > The migration include the removal of palantir's consistent versions plugin. > Dev list thread: > [https://lists.apache.org/thread/wh6c0x2ncbpd61pwwddtv3l256lv9kr5] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17406) Introduce Gradle Version Catalogs
[ https://issues.apache.org/jira/browse/SOLR-17406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christos Malliaridis updated SOLR-17406: Attachment: Screenshot 2025-01-13 012825.png > Introduce Gradle Version Catalogs > - > > Key: SOLR-17406 > URL: https://issues.apache.org/jira/browse/SOLR-17406 > Project: Solr > Issue Type: Improvement > Components: Gradle >Affects Versions: main (10.0) >Reporter: Christos Malliaridis >Assignee: Christos Malliaridis >Priority: Minor > Labels: dependencies, gradle, pull-request-available > Attachments: Screenshot 2025-01-13 012825.png > > Time Spent: 8h > Remaining Estimate: 0h > > With Gradle it is possible to manage versions and dependencies in gradle > files via version catalogs. This allows us to cleanup dependency resolution > and move various versions from across the project to a single file. > Dawid Weiss demonstrated in [Lucene PR > #13484|https://github.com/apache/lucene/pull/13484/] such a migration > together with a few improvements in the gradle build files that could be > addressed in this ticket aswell. > The migration include the removal of palantir's consistent versions plugin. > Dev list thread: > [https://lists.apache.org/thread/wh6c0x2ncbpd61pwwddtv3l256lv9kr5] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17406) Introduce Gradle Version Catalogs
[ https://issues.apache.org/jira/browse/SOLR-17406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christos Malliaridis updated SOLR-17406: Attachment: Screenshot 2025-01-13 012825.png > Introduce Gradle Version Catalogs > - > > Key: SOLR-17406 > URL: https://issues.apache.org/jira/browse/SOLR-17406 > Project: Solr > Issue Type: Improvement > Components: Gradle >Affects Versions: main (10.0) >Reporter: Christos Malliaridis >Assignee: Christos Malliaridis >Priority: Minor > Labels: dependencies, gradle, pull-request-available > Attachments: Screenshot 2025-01-13 012825.png > > Time Spent: 8h > Remaining Estimate: 0h > > With Gradle it is possible to manage versions and dependencies in gradle > files via version catalogs. This allows us to cleanup dependency resolution > and move various versions from across the project to a single file. > Dawid Weiss demonstrated in [Lucene PR > #13484|https://github.com/apache/lucene/pull/13484/] such a migration > together with a few improvements in the gradle build files that could be > addressed in this ticket aswell. > The migration include the removal of palantir's consistent versions plugin. > Dev list thread: > [https://lists.apache.org/thread/wh6c0x2ncbpd61pwwddtv3l256lv9kr5] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17406) Introduce Gradle Version Catalogs
[ https://issues.apache.org/jira/browse/SOLR-17406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christos Malliaridis updated SOLR-17406: Attachment: (was: Screenshot 2025-01-13 012825.png) > Introduce Gradle Version Catalogs > - > > Key: SOLR-17406 > URL: https://issues.apache.org/jira/browse/SOLR-17406 > Project: Solr > Issue Type: Improvement > Components: Gradle >Affects Versions: main (10.0) >Reporter: Christos Malliaridis >Assignee: Christos Malliaridis >Priority: Minor > Labels: dependencies, gradle, pull-request-available > Attachments: Screenshot 2025-01-13 012825.png > > Time Spent: 8h > Remaining Estimate: 0h > > With Gradle it is possible to manage versions and dependencies in gradle > files via version catalogs. This allows us to cleanup dependency resolution > and move various versions from across the project to a single file. > Dawid Weiss demonstrated in [Lucene PR > #13484|https://github.com/apache/lucene/pull/13484/] such a migration > together with a few improvements in the gradle build files that could be > addressed in this ticket aswell. > The migration include the removal of palantir's consistent versions plugin. > Dev list thread: > [https://lists.apache.org/thread/wh6c0x2ncbpd61pwwddtv3l256lv9kr5] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-17619) Generate CHANGELOG.md (formerly CHANGES.txt) via logchange
David Smiley created SOLR-17619: --- Summary: Generate CHANGELOG.md (formerly CHANGES.txt) via logchange Key: SOLR-17619 URL: https://issues.apache.org/jira/browse/SOLR-17619 Project: Solr Issue Type: Task Components: Build Reporter: David Smiley The [logchange|https://github.com/logchange/logchange] tool helps projects maintain a log of changes. Each change (e.g. from a PR) will no longer edit a CHANGES.txt file; instead it will include a _new_ YAML file in an appropriate directory with others for the next Solr version. The release process will execute the tool, which will build a CHANGELOG.md file and will probably also do something with the YAML files (remove?). Decide the most convenient way for us to run the tool for change authors. Could a gradle task do it? See [this issue|https://github.com/logchange/logchange/issues/397] filed on the logchange project. Outcome of this issue: * a logchange tool configuration file -- logchange-config.yml * Solr 10's CHANGES.txt entries converted to YAML. (start this issue by doing only a few before over-investing) * a dev-docs page ** for contributors/everyone: basic info explaining how each new change should be recorded. Explain how to run the tool to generate the YAML file. What field(s) matter the most; what should be ignored. Link to further details. ** for release manager: how to produce CHANGELOG.md. Link to further details. Ultimately this will probably move to the release wizard in some fashion. TBD: CHANGES.txt < 10 and CHANGELOG.md > 10 ? TBD: changes.html generation in the release process will be removed or will change. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17406) Introduce Gradle Version Catalogs
[ https://issues.apache.org/jira/browse/SOLR-17406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christos Malliaridis updated SOLR-17406: Attachment: Screenshot 2025-01-13 014721.png > Introduce Gradle Version Catalogs > - > > Key: SOLR-17406 > URL: https://issues.apache.org/jira/browse/SOLR-17406 > Project: Solr > Issue Type: Improvement > Components: Gradle >Affects Versions: main (10.0) >Reporter: Christos Malliaridis >Assignee: Christos Malliaridis >Priority: Minor > Labels: dependencies, gradle, pull-request-available > Attachments: Screenshot 2025-01-13 012825.png, Screenshot 2025-01-13 > 014721.png, Screenshot 2025-01-13 014818.png > > Time Spent: 8h > Remaining Estimate: 0h > > With Gradle it is possible to manage versions and dependencies in gradle > files via version catalogs. This allows us to cleanup dependency resolution > and move various versions from across the project to a single file. > Dawid Weiss demonstrated in [Lucene PR > #13484|https://github.com/apache/lucene/pull/13484/] such a migration > together with a few improvements in the gradle build files that could be > addressed in this ticket aswell. > The migration include the removal of palantir's consistent versions plugin. > Dev list thread: > [https://lists.apache.org/thread/wh6c0x2ncbpd61pwwddtv3l256lv9kr5] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17406) Introduce Gradle Version Catalogs
[ https://issues.apache.org/jira/browse/SOLR-17406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christos Malliaridis updated SOLR-17406: Attachment: Screenshot 2025-01-13 014818.png > Introduce Gradle Version Catalogs > - > > Key: SOLR-17406 > URL: https://issues.apache.org/jira/browse/SOLR-17406 > Project: Solr > Issue Type: Improvement > Components: Gradle >Affects Versions: main (10.0) >Reporter: Christos Malliaridis >Assignee: Christos Malliaridis >Priority: Minor > Labels: dependencies, gradle, pull-request-available > Attachments: Screenshot 2025-01-13 012825.png, Screenshot 2025-01-13 > 014721.png, Screenshot 2025-01-13 014818.png > > Time Spent: 8h > Remaining Estimate: 0h > > With Gradle it is possible to manage versions and dependencies in gradle > files via version catalogs. This allows us to cleanup dependency resolution > and move various versions from across the project to a single file. > Dawid Weiss demonstrated in [Lucene PR > #13484|https://github.com/apache/lucene/pull/13484/] such a migration > together with a few improvements in the gradle build files that could be > addressed in this ticket aswell. > The migration include the removal of palantir's consistent versions plugin. > Dev list thread: > [https://lists.apache.org/thread/wh6c0x2ncbpd61pwwddtv3l256lv9kr5] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17221: Http2SolrClient merges case sensitive solr params [solr]
dsmiley commented on code in PR #3028:
URL: https://github.com/apache/solr/pull/3028#discussion_r1912565128
##
solr/solrj/src/test/org/apache/solr/client/solrj/impl/HttpSolrClientTestBase.java:
##
Review Comment:
I believe the only test changes needed are the ones you did here in this
file. The other two source files extend this one and thus will run the same
test code (right?).
##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/Http2SolrClient.java:
##
@@ -784,7 +784,7 @@ private Request fillContentStream(
}
} else {
// application/x-www-form-urlencoded
- Fields fields = new Fields();
+ Fields fields = new Fields(true);
Iterator iter = wparams.getParameterNamesIterator();
while (iter.hasNext()) {
Review Comment:
This whole else block could be replaced with something very close to this,
notwisthanding the annoying leading question mark to chop off of toQueryString:
```
req.body(new StringRequestContent("application/x-www-form-urlencoded",
wparams.toQueryString(), FALLBACK_CHARSET));
```
I suppose if there are no params then we don't even need to send a body.
WDYT @jdyer1 ?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
