Re: [PR] SOLR-17406: Introduce Version Catalogs [solr]
malliaridis commented on code in PR #2706: URL: https://github.com/apache/solr/pull/2706#discussion_r1836036572 ## solr/licenses/netty-NOTICE.txt: ## @@ -162,9 +170,9 @@ This product optionally depends on 'JBoss Marshalling', an alternative Java serialization API, which can be obtained at: * LICENSE: -* license/LICENSE.jboss-marshalling.txt (GNU LGPL 2.1) +* license/LICENSE.jboss-marshalling.txt (Apache License 2.0) Review Comment: The updates are originally coming from https://github.com/apache/solr/pull/2702. I looked up the repository and noticed a few changes there. It's probably best to make it a required step of the dependency update procedure. It should also be quite simple to find and copy-paste the files if they are on GitHub (or part of the jar, which is often not the case). Apparently I missed to update the license and notice file of the rest of the netty dependencies. Since they come all from the same repository, it is probably best to merge the files into netty-LICENSE.txt and netty-NOTICE-txt by simply removing the other files. Should be part of [SOLR-15929](https://issues.apache.org/jira/browse/SOLR-15929) though. -- 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-15929) Clean up NOTICE and LICENSE files for Solr
[
https://issues.apache.org/jira/browse/SOLR-15929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897094#comment-17897094
]
Christos Malliaridis commented on SOLR-15929:
-
I am not sure what the goal of the spreadsheet would be, could you elaborate?
This sounds like ahuge maintenance effort if it is not a one-time thing.
I believe the current tooling notifies about files that are no longer needed,
if that's what you mean. What I also saw is that we can merge a few LICENSE and
NOTICE files together that coming from the same repository, like all the netty
dependencies can share the same netty-LICENSE.txt and netty-NOTICE.txt file.
I'd love to see a variant-specific output. About the SBOM: Dawid Weiss
mentioned that in [a
thread|https://lists.apache.org/thread/7pth7286zmq8kcc18gx8yg62y8ktbsgf]. We
may look into it in more detail if it is worth the effort and maintenance cost.
What I am also worried about is modules that have the same artifact name but
different group name. The current naming convention would cause a naming
conflict, resulting in one LICENSE and NOTICE file for two completely different
dependencies. I am not sure if this is "critical" though.
> Clean up NOTICE and LICENSE files for Solr
> --
>
> Key: SOLR-15929
> URL: https://issues.apache.org/jira/browse/SOLR-15929
> Project: Solr
> Issue Type: Improvement
>Reporter: Jan Høydahl
>Priority: Major
>
> Spinoff from SOLR-15862 and SOLR-2406:
> We need a total cleanup of both these files
> * Move lots of (C) notices from NOTICE to LICENSE file
> * Cross-check that we list all dependencies, and that removed deps (such as
> for DIH etc) are removed from NOTICE/LICENSE
> I wonder if
> [https://github.com/apache/solr/blob/main/solr/licenses/README.committers.txt]
> should also be relocated to either `dev-docs/` or `help/` to make it easier
> to find. It is hard to get the license/notice stuff right, so we need a good
> guide for committers!
> See [https://infra.apache.org/licensing-howto.html] for the requirements. PS:
> Any preference whether we should rename the files without {{.txt}} suffix?
> Also, our source and binary distributions are quite different, and would
> ideally have different LICENSE and NOTICE files compared to the binary
> distro. I think the Apache Whisker tool could potientailly help with this
> [https://creadur.apache.org/whisker/index.html] but have not looked deeply.
--
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
[I] Unable to install solr-operator 0.8.1 - zookeeper operator post install job failure [solr-operator]
jamesla opened a new issue, #728: URL: https://github.com/apache/solr-operator/issues/728 I'm just getting started with this operator and I'm getting a failure on the zookeeper operators postinstall job. Works fine if I install the zookeeper operator by itself. To reproduce: 1. `minikube start` 2. `helm install solr-operator apache-solr/solr-operator --version 0.8.1` You will see that the zookeeper post install jobs fail, they output no logs and nothing about the issue is logged to the Kubernetes event log. Should this be working? -- 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.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] [Resolved] (SOLR-17443) While using Solr 7.7.2, I attempted to migrate documents between collections using the Collections API. Despite receiving successful responses, no documents were migrate
[
https://issues.apache.org/jira/browse/SOLR-17443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arda resolved SOLR-17443.
-
Resolution: Workaround
I encountered an issue where the Solr API returned a success message for
document migration but didn't actually migrate the documents. To address this,
I developed a Python script as a workaround for migrating documents between
collections. This script may help others facing the same issue until a
permanent solution is found. Feel free to review and contribute to the
repository if you have any improvements or suggestions.
Here, you can find the code and detailed instructions in the following GitHub
repository:
[GitHub Repository
Link|https://github.com/ardatezcan1/solr_migrate_api_solution/tree/main]
This is not a direct fix for the API issue but can be used as an alternative
approach to ensure successful migration.
> While using Solr 7.7.2, I attempted to migrate documents between collections
> using the Collections API. Despite receiving successful responses, no
> documents were migrated.
> ---
>
> Key: SOLR-17443
> URL: https://issues.apache.org/jira/browse/SOLR-17443
> Project: Solr
> Issue Type: Bug
> Components: JSON Request API, SolrCloud, v2 API
>Affects Versions: 7.7.2
>Reporter: Arda
>Priority: Minor
> Labels: collection-api
>
> *Issue Summary*
> I am using Solr version 7.7.2 and encountered an issue while attempting to
> migrate documents from one collection to another using the Collections API.
> Despite receiving a successful response, the documents are not actually
> migrated. I followed the official Solr documentation for data migration:
> [https://solr.apache.org/guide/7_7/collections-api.html#migrate]
> Here are the commands I used:
>
> 1- curl -k -g--negotiate -u:
> "https://‹solr_server_hostname>:/solr/admin/collections?action=migrate&collection=&split.key=compositeId&target.collection="
>
> 2- curl -k -g--negotiate -u:
> "https:///solr/admin/collections?action=MIGRATE&collection=&split.key=!&target.collection=&async=1000"
>
> I tried using a generic split key ("!") as the routing key prefix was
> unknown. However, in bash, this caused a -bash: !: event not found error. To
> avoid this, I also attempted using escaped characters like \! and %21.
> Despite these modifications, all commands returned a successful response but
> did not actually migrate the documents.
--
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] [Resolved] (SOLR-17460) Error During Collection Migration from Solr 7.0 to Solr 8.4: Missing Files and Shard Restoration Failures
[ https://issues.apache.org/jira/browse/SOLR-17460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arda resolved SOLR-17460. - Resolution: Workaround To successfully migrate the collection with all data intact, I followed these steps: *1. Prepare the Collection Configuration:* First, I retrieved the Solr collection's configuration files from the Solr 7.0 cluster and modified them to be compatible with Solr 8.4. I then created the new collection on the Solr 8.4 cluster without any data, using the updated configuration. *2. Copy Shard Core Nodes Locally:* I copied each shard’s core nodes from the HDFS path of the Solr 7.0 cluster to a local directory. Using the Solr Web UI, I identified which nodes corresponded to each shard and replica for the collection. Note that the core node paths may differ for each collection. Here’s an example of the commands used: _# Shard 1, 2, and 3_ hdfs dfs --copyToLocal /core_node1 _# Shard 1_ hdfs dfs --copyToLocal /core_node2 _# Shard 2_ hdfs dfs --copyToLocal /core_node3 _# Shard 3_ _# Replica nodes_ hdfs dfs --copyToLocal /core_node6 _# Replica 1_ hdfs dfs --copyToLocal /core_node8 _# Replica 2_ hdfs dfs --copyToLocal /core_node10 _# Replica 3_ After copying the core node files locally, I transferred them to the Solr 8.4 cluster. *3. Copy Shard Core Nodes to HDFS on the New Cluster:* I copied the shard core node files into the appropriate HDFS directory on the new Solr 8.4 cluster. *Important:* The shard core nodes must be copied into the exact corresponding location. For example, if shard 1 was stored in *_core_node1_* in the old cluster and is now assigned to *_core_node5_* in the new cluster, you must copy the data from *_core_node1_* to *_core_node5._* Example commands: _# Copy shard 1, 2, and 3 core nodes_ hdfs dfs -put /core_node1 /core_node5 _# Shard 1_ hdfs dfs -put /core_node2 /core_node6 _# Shard 2_ hdfs dfs -put /core_node3 /core_node7 _# Shard 3_ _# Copy replica core nodes_ hdfs dfs -put /core_node6 /core_node11 _# Replica 1_ hdfs dfs -put /core_node8 /core_node12 _# Replica 2_ hdfs dfs -put /core_node10 /core_node9 _# Replica 3_ *4. Adjust Ownership in HDFS:* I changed the ownership of the collection’s HDFS path on the new cluster to ensure Solr had the necessary permissions to access the data. hdfs dfs -chown -R solr:solr To verify that the files were correctly copied, I compared the file sizes on both clusters using the following command: hdfs dfs -du -s -h -v -x *5. Reload the Collection:* Finally, I reloaded the collection via the Solr Web UI on the new Solr 8.4 cluster. To confirm the successful migration of all data, I queried the collection and verified that the document count matched the original. With these steps, I was able to migrate the entire collection along with all data. You can check the document count by running a simple query to verify that the migration was successful. > Error During Collection Migration from Solr 7.0 to Solr 8.4: Missing Files > and Shard Restoration Failures > - > > Key: SOLR-17460 > URL: https://issues.apache.org/jira/browse/SOLR-17460 > Project: Solr > Issue Type: Bug > Components: hdfs, SolrCloud >Affects Versions: 7.0, 8.4 >Reporter: Arda >Priority: Minor > Labels: backup, restore > > I was attempting to migrate a collection with 3 shards from a Solr 7.0 > cluster to a Solr 8.4 cluster. The data is stored in HDFS. I followed the > backup-restore process but encountered issues with two of the shards during > the restoration. > h1. *Migration Process:* > *1-* *Backup Command:* To avoid timeouts, I initiated the backup with an > async parameter: > curl -k --negotiate -u : > 'https://:/solr/admin/collections?action=BACKUP&name=&collection=x&location=& > async=12346' > *2- Copy Backup to Local:* After the backup, I copied the data from HDFS to > the local filesystem: > hdfs dfs --copyToLocal > *3- Transfer Backup to New Cluster:* I then copied the backup files from the > older Solr node to the newer one: > scp -pr @: > *4- Prepare New HDFS Path:* On the new Solr cluster, I created a new > directory in HDFS and adjusted ownership: > hdfs dfs -mkdir > hdfs dfs -chown solr:solr > *5- Copy Backup to New HDFS Location:* I transferred the backup data from > local to the new HDFS path. Before that, I deleted > "queryDocAuthorization" parts from solrconfig.xml file to become > compatible with the newer version. > hdfs dfs --copyFromLocal > *6- Restore Collection:* Finally, I ran the restore command: > curl -k --negotiate -u : > 'https://:/solr/admin/collections?action=RESTORE&name=&collection=x&location=& > async=12345' > h1. > *Issue:* > After the restore process completed, I foun
Re: [PR] CLI: Improve console output of auth command [solr]
epugh commented on PR #2857: URL: https://github.com/apache/solr/pull/2857#issuecomment-2466695379 > @epugh Is something like this worth a ticket or added in the changes (planning to backport it)? Normally I would say no. However, since it improves our security posture? That might be worth going in CHANGES.txt. -- 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-17484) Prometheus Exporter should efficiently work without ZK dependency
[ https://issues.apache.org/jira/browse/SOLR-17484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897015#comment-17897015 ] Christos Malliaridis commented on SOLR-17484: - Yeah, I thought it would do more than just cherrypicking, but on Windows that's the only thing that works right now, so it doesn't makes much sense for me to use it either. I'll stick with the IDE instead. > Prometheus Exporter should efficiently work without ZK dependency > - > > Key: SOLR-17484 > URL: https://issues.apache.org/jira/browse/SOLR-17484 > Project: Solr > Issue Type: Improvement > Components: contrib - prometheus-exporter >Reporter: David Smiley >Priority: Major > > The Prometheus Exporter, when pointing at SolrCloud, CloudSolrClient with a > ZK connecting backing it. This issue proposes switching it to the Solr/HTTP > based ClusterState provider. > Note there are some performance issues with calls it makes to > CloudSolrClient.getClusterState which shifts from a simple getter to a remote > call that returns the entire cluster state. Perhaps out of scope or a > dependency? -- 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-17151 Check limits between calls to components in SearchHandler [solr]
gus-asf commented on PR #2801: URL: https://github.com/apache/solr/pull/2801#issuecomment-2466793917 Crave seems to be stalled entirely. Tests pass locally, merging -- 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-17151) Review current usage of QueryLimits to ensure complete coverage
[
https://issues.apache.org/jira/browse/SOLR-17151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897020#comment-17897020
]
ASF subversion and git services commented on SOLR-17151:
Commit 125fc3fb70c6873e7f1b93c160b9f9522e64213f in solr's branch
refs/heads/main from Gus Heck
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=125fc3fb70c ]
SOLR-17151 Check limits between calls to components in SearchHandler (#2801)
> Review current usage of QueryLimits to ensure complete coverage
> ---
>
> Key: SOLR-17151
> URL: https://issues.apache.org/jira/browse/SOLR-17151
> Project: Solr
> Issue Type: Sub-task
> Components: Query Limits
>Reporter: Andrzej Bialecki
>Assignee: Gus Heck
>Priority: Major
> Labels: pull-request-available
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Resource usage by a query is not limited to the actual search within
> {{QueryComponent}}. Other components invoked by {{SearchHandler}} may
> significantly contribute to this usage, either before or after the
> {{QueryComponent}}.
> Those components that already use {{QueryTimeout}} either directly or
> indirectly will properly observe the limits and terminate if needed. However,
> other components may be expensive or misbehaving but fail to observe the
> limits imposed on the end-to-end query processing.
> One such obvious place where we could add this check is where the
> {{SearchHandler}} loops over {{SearchComponent}-s - it should call explicitly
> {{QueryLimits.shouldExit()}} to ensure that even if previously executed
> component ignored the limits they will be still enforced at the
> {{SearchHandler}} level. There may be other places like this, too.
--
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-17151 Check limits between calls to components in SearchHandler [solr]
gus-asf merged PR #2801: URL: https://github.com/apache/solr/pull/2801 -- 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] [Resolved] (SOLR-2292) Lock down NamedList API, remove inefficent and esoteric methods
[
https://issues.apache.org/jira/browse/SOLR-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved SOLR-2292.
Resolution: Won't Fix
Marking as won't-fix. It's not quite clear what the proposal really is, other
than reviewing/auditing.
> Lock down NamedList API, remove inefficent and esoteric methods
> ---
>
> Key: SOLR-2292
> URL: https://issues.apache.org/jira/browse/SOLR-2292
> Project: Solr
> Issue Type: Task
>Reporter: Chris M. Hostetter
>Priority: Major
> Fix For: 6.0, 4.9
>
>
> Over in SOLR-2288, rmuir made some good points about locking down the
> NamedList API to protect people...
> {quote}
> I looked at your patch, and personally I think NamedList should really be
> type-safe.
> If users want to use it in a type-unsafe way, thats fine, but *the container
> itself shouldn't be List*.
> {quote}
> ...
> {quote}
> Separately, i just want to say the following about NamedList:
> All uses of this API should really be reviewed. I'm quite aware that it warns
> you about the fact that its slow for certain operations,
> but in my opinion these *slow operations such as get(String, int) should be
> deprecated and removed*.
> Any users that are using NamedList in this way, especially in loops, are very
> likely using the wrong datastructure.
> {quote}
> (emphasis added by me)
--
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-17406: Introduce Version Catalogs [solr]
dsmiley commented on code in PR #2706: URL: https://github.com/apache/solr/pull/2706#discussion_r1835784148 ## solr/licenses/netty-NOTICE.txt: ## @@ -162,9 +170,9 @@ This product optionally depends on 'JBoss Marshalling', an alternative Java serialization API, which can be obtained at: * LICENSE: -* license/LICENSE.jboss-marshalling.txt (GNU LGPL 2.1) +* license/LICENSE.jboss-marshalling.txt (Apache License 2.0) Review Comment: I checked this -- looks accurate. Then I got curious and searched out entire licenses folder for "LGPL". netty-transport-native-epoll-NOTICE.txt (and unix-common-NOTICE.txt) also makes a reference to LGPL but it's via the same jboss-marshalling line you are correcting here. So I think they can also be updated. -- 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-912) org.apache.solr.common.util.NamedList - Typesafe efficient variant - ModernNamedList introduced - implementing the same API as NamedList
[
https://issues.apache.org/jira/browse/SOLR-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897044#comment-17897044
]
Gus Heck commented on SOLR-912:
---
I've always heard that this class is efficient. Are there any (modern)
benchmarks that prove this?
Also when I read the javadoc for named list it says it provides:
{code:java}
* Unlike Maps:
*
*
* Names may be repeated
* Order of elements is maintained
* Elements may be accessed by numeric index
* Names and Values can both be null
*
* {code}
But I read that and wonder why these things (other than perhaps order) are
considered benefits.
* What use do we have for a null key?
* I know there are a couple of places in our API that use repeated JSON keys,
but I am strongly of the opinion that this was not a good decision in those
places because most of the world expects json structures to be easily stored in
a map, and many libraries default to this. It's true that in theory a URL
parameter list will drop right in, but I'm unclear what that really buys us
since HttpServletRequest.getParameterMap coalesces keys and returns a
Map anyway... Also note that jetty implements getParameter via
a multimap already.
{code:java}
@Override
public String getParameter(String name)
{
return getParameters().getValue(name, 0);
}
private MultiMap getParameters(){code}
* Sure access by index is fast but when I look at access by index usage in the
code base, the first 20 things I looked at were using this "fast access" inside
a loop iterating the entire named list.
I've never found NamedList convenient or more helpful than standard
collections, and it's only justification for existence seems to be is it's
legendary efficiency.
> org.apache.solr.common.util.NamedList - Typesafe efficient variant -
> ModernNamedList introduced - implementing the same API as NamedList
>
>
> Key: SOLR-912
> URL: https://issues.apache.org/jira/browse/SOLR-912
> Project: Solr
> Issue Type: Improvement
> Components: search
> Environment: Tomcat 6, JRE 6, Solr 1.3+ nightlies
>Reporter: Karthik K
>Priority: Minor
> Attachments: NLProfile.java, SOLR-912.patch, SOLR-912.patch
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> The implementation of NamedList - while being fast - is not necessarily
> type-safe. I have implemented an additional implementation of the same -
> ModernNamedList (a type-safe variation providing the same interface as
> NamedList) - while preserving the semantics in terms of ordering of elements
> and allowing null elements for key and values (keys are always Strings ,
> while values correspond to generics ).
--
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-17540: Remove Hadoop Auth Module [solr]
dsmiley commented on PR #2835: URL: https://github.com/apache/solr/pull/2835#issuecomment-2466954428 Please do not merge this until after #2706 so we don't give Malliaridis a tough time over there. That one should be merged soon. -- 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-17540: Remove Hadoop Auth Module [solr]
dsmiley commented on PR #2835: URL: https://github.com/apache/solr/pull/2835#issuecomment-2466955710 So Kerberos Auth is going away with this. Be sure to highlight this in CHANGES.txt and in JIRA. To me, Hadoop-Auth is a forgettable implementation detail (I didn't know _really_ know what this is) to the effective industry feature (I know of Kerberos). If you search our ref guide for "Kerberos", it still exists in this PR. See `authentication-and-authorization-plugins.adoc`. -- 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-17406: Introduce Version Catalogs [solr]
risdenk commented on code in PR #2706:
URL: https://github.com/apache/solr/pull/2706#discussion_r1835795810
##
solr/core/src/java/org/apache/solr/update/processor/ClassificationUpdateProcessorFactory.java:
##
@@ -92,8 +92,7 @@ public void init(final NamedList args) {
String algorithmString = params.get(ALGORITHM_PARAM);
Algorithm classificationAlgorithm;
try {
-if (algorithmString == null
-|| Algorithm.valueOf(algorithmString.toUpperCase(Locale.ROOT)) ==
null) {
Review Comment:
This doesn't look related to version catalogs?
##
gradle/libs.versions.toml:
##
@@ -0,0 +1,460 @@
+# 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.
+[versions]
+adobe-testing-s3mock = "2.17.0"
+amazon-awssdk = "2.26.19"
+# @keep Antora version used in ref-guide
+antora = "3.1.4"
+# @keep Most recent commit as of 2022-06-24, this repo does not have tags
+antora-default-ui = "51ad811622394027afb4e182c2fdabc235ae04dd"
+# @keep Antora Lunr extensions version used in ref-guide
+antora-lunr-extension = "1.0.0-alpha.8"
+apache-calcite = "1.37.0"
+apache-calcite-avatica = "1.25.0"
+apache-commons-collections4 = "4.4"
+apache-commons-compress = "1.26.1"
+apache-commons-configuration2 = "2.11.0"
+apache-commons-exec = "1.4.0"
+apache-commons-lang3 = "3.15.0"
+apache-commons-math3 = "3.6.1"
+# @keep for version alignment
+apache-commons-text = "1.12.0"
+apache-curator = "5.7.1"
+apache-hadoop = "3.4.0"
+apache-hadoop-thirdparty = "1.2.0"
+apache-httpcomponents-httpclient = "4.5.14"
+apache-httpcomponents-httpcore = "4.4.16"
+apache-httpcomponents-httpmime = "4.5.14"
+apache-kafka = "3.7.1"
+apache-kerby = "2.0.3"
+apache-log4j = "2.21.0"
+apache-lucene = "9.11.1"
+apache-opennlp = "1.9.4"
+apache-poi = "5.2.2"
+apache-rat = "0.15"
+apache-tika = "1.28.5"
+apache-tomcat = "6.0.53"
+apache-zookeeper = "3.9.2"
+# @keep for version alignment
+apiguardian = "1.1.2"
+aqute-bnd = "6.4.1"
+# @keep Asciidoctor mathjax version used in ref-guide
+asciidoctor-mathjax = "0.0.9"
+# @keep Asciidoctor tabs version used in ref-guide
+asciidoctor-tabs = "1.0.0-beta.6"
+# @keep bats-assert (node) version used in packaging
+bats-assert = "2.0.0"
+# @keep bats-core (node) version used in packaging
+bats-core = "1.8.2"
+# @keep bats-file (node) version used in packaging
+bats-file = "0.3.0"
+bc-jose4j = "0.9.6"
+benmanes-caffeine = "3.1.8"
+benmanes-versions = "0.51.0"
+bouncycastle = "1.78.1"
+# @keep Browserify version used in ref-guide
+browserify = "17.0.0"
+carrot2-core = "4.5.1"
+carrotsearch-dependencychecks = "0.0.9"
+carrotsearch-hppc = "0.10.0"
+carrotsearch-randomizedtesting = "2.8.1"
+# @keep for version alignment
+checkerframework = "3.44.0"
+codehaus-woodstox = "4.2.2"
+commons-cli = "1.9.0"
+commons-codec = "1.17.1"
+commons-collections = "3.2.2"
+commons-io = "2.15.1"
+cutterslade-analyze = "1.10.0"
+cybozulabs-langdetect = "1.1-20120112"
+diffplug-spotless = "6.5.2"
+dropwizard-metrics = "4.2.26"
+eclipse-ecj = "3.39.0"
+eclipse-jetty = "10.0.22"
+eclipse-jettytoolchain = "4.0.6"
+# @keep jgit version used by git-statuts.gradle
Review Comment:
typo `git-status.gradle`
##
solr/core/src/test/org/apache/solr/handler/admin/api/UnloadCoreAPITest.java:
##
@@ -56,7 +56,6 @@ public void setUp() throws Exception {
public void testValidUnloadCoreAPIResponse() throws Exception {
SolrJerseyResponse response = unloadCoreAPI.unloadCore(coreName,
getUnloadCoreRequestBodyObj());
assertEquals(0, response.responseHeader.status);
-assertNotNull(response.responseHeader.qTime);
Review Comment:
Why did this test change?
##
solr/core/src/test/org/apache/solr/handler/admin/IndexSizeEstimatorTest.java:
##
@@ -227,8 +227,9 @@ public void testIntegration() throws Exception {
(k, v) -> {
double size = fromHumanReadableUnits((String) v);
double sampledSize = fromHumanReadableUnits((String)
sampledFieldsBySize.get(k));
-assertNotNull(
Review Comment:
Why did this test change?
##
solr/core/src/test/org/apache/solr/handler/admin/api/ReloadCoreAPITest.java:
##
@@ -57,7 +57,6 @@ public void setUp() throws Exception {
public void t
Re: [PR] SOLR-17334: Enable coordinator nodes to handle requests other than `/select` [solr]
github-actions[bot] commented on PR #2527: URL: https://github.com/apache/solr/pull/2527#issuecomment-2466996252 This PR has had no activity for 60 days and is now labeled as stale. Any new activity will remove the stale label. To attract more reviewers, please tag people who might be familiar with the code area and/or notify the d...@solr.apache.org mailing list. To exempt this PR from being marked as stale, make it a draft PR or add the label "exempt-stale". If left unattended, this PR will be closed after another 60 days of inactivity. Thank you for your contribution! -- 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
