Re: "solr start -e techproducts" failing on MacOS

59 > > > > > > As you already found out you can also just disable the security > manager - > > > here is a one liner that doesn't require changing any files either. > > > > > > SOLR_SECURITY_MANAGER_ENABLED=false ./bin/solr start -f > >

Re: SolrBot running again

Nice to see it running again. Please note that for the PRs that have a green checkmark you still have to do some basic checks before merging, like making sure the license and notice files are up-to-date with the files of the dependency. More information about this can be found in help/dependencies

Re: "solr start -e techproducts" failing on MacOS

I have faced the same issue recently. There is a configuration option in bin/solr.in.sh for the security manager: #SOLR_SECURITY_MANAGER_ENABLED=true Removing the comment and setting it to false worked for me. On Wed, 21 May 2025, 23:19 Rahul Goswami, wrote: > Sanjay, > Th

Re: Error executing "gradlew assemble"

> Rahul > > On Sat, May 17, 2025 at 9:20 AM Christos Malliaridis < > c.malliari...@gmail.com> wrote: > > > Thanks for reporting this. > > > > Jason has reported similar issues on Slack and I forgot to investigate > it. > > You should be able to worka

Re: Error executing "gradlew assemble"

Thanks for reporting this. Jason has reported similar issues on Slack and I forgot to investigate it. You should be able to workaround this by using `production=true` in your gradle.properties file. I have also found a few reports online and workarounds that didn't work straight away, so I will in

Re: Planned OS Upgrade for lucene-solr-1 and lucene-solr-2

What steps are still remaining before we can turn off the old nodes?* Best, Christos On Mon, Apr 7, 2025 at 8:09 PM Christos Malliaridis wrote: > I've requested an upgrade here: > https://issues.apache.org/jira/browse/INFRA-26732 > > I hope I didn't forget anything. :) > &g

Re: Slow build and startup of tests in intellij

Hey Colvin, I would probably not blame the UI module for that, but it is mentioned in the output. If I understand it correctly, IntelliJ IDEA cannot be used to run the tests as proposed before, because the Kotlin UI module's WebAssembly target is not supported? If that is the case, could you try d

Re: Planned OS Upgrade for lucene-solr-1 and lucene-solr-2

; > Hi, > > > > go ahead. I preserved some config files. Actually the Gradle builds > > are easier to maintain as Ant, so basically it is just 2 files. > > > > Uwe > > > > Am 02.04.2025 um 17:21 schrieb Uwe Schindler: > >> Oh sorry, will

Re: Planned OS Upgrade for lucene-solr-1 and lucene-solr-2

@Uwe Did you have the time to run a backup of the home directory? I would proceed and open an infra ticket if we are ready, I just need to know what "all packages we need for Jenkins Slaves" includes, as I am not sure how to look this up to include it in the ticket. Christos Hi, > I tried the d

Re: Planned OS Upgrade for lucene-solr-1 and lucene-solr-2

ys no setup necessary at all > > - it booted straight out of box and Jenkins autostarted and went back > > to work). > > > > Important info: The setup of the nodes inside Jenkins can only be done > > by Infra, we have no access. Generally it is better to not change to &g

Re: Planned OS Upgrade for lucene-solr-1 and lucene-solr-2

On Wed, Mar 26, 2025 at 8:36 PM David Smiley wrote: > Was it actually only one machine that was too out-of-date? > > On Wed, Mar 26, 2025 at 1:05 PM Christos Malliaridis < > malliari...@apache.org> > wrote: > > > Hello everyone, > > > > In consultation wit

Planned OS Upgrade for lucene-solr-1 and lucene-solr-2

Hello everyone, In consultation with David Smiley, I am planning to request an OS upgrade for our build nodes *lucene-solr-1* and *lucene-solr-2* on Monday, March 31, as they are running older operating systems and causing OS-related build errors in the Solr project. Since the nodes will be repla

Re: New UI (Kotlin) module: maybe separate repo/build but included as dependency?

gt; > > Can someone expand on the downsides of having the Kotlin UI code in > > the main repo? Or the concrete benefits of separating it out? > > > > I know there were some CI job failures around the time of the initial > > merge, but I haven't noticed it

Re: New UI (Kotlin) module: maybe separate repo/build but included as dependency?

I was considering this from the beginning, and I was not aware of the whole stack we were using for building Solr. I thought that the GitHub workflows would be sufficient to guarantee at least the build processes to succeed in all our CI/CD environments, but I was wrong. Since the UI is generating

Re: [JENKINS] Solr » Solr-Test-main-s390x - Build # 902 - Still Failing!

Thanks for getting this to my attention. I have created https://github.com/apache/solr/pull/3261 for temporarily disabling the new UI module via gradle properties. This can be used for other operating systems if s390x is not the only one, and also for the builds where alternative JDKs are used. Wh

Re: [DISCUSS] SIP-16: Distinguishing Single Node and Cluster Operation Modes at API level

n? > > I love these API suggestions, from a purely aesthetic/cosmetic > perspective. But there are some obstacles IMO - the biggest one being > limitations in Solr's featureset as it stands today. > > Take "cluster properties" and "node roles" as examples.

Re: Bugfix release Solr 9.8.1

The PR https://github.com/apache/solr/pull/3196 contains some ref guide fixes. Probably not worth mentioning in the changelog, but would not hurt cherrypicking them in this release. :) On 2025/02/17 21:22:56 Houston Putman wrote: > NOTICE: > > I am now preparing for a bugfix release from branch

[DISCUSS] SIP-16: Distinguishing Single Node and Cluster Operation Modes at API level

Hello everyone, I am looking into the v2 API and I was wondering what our final design will look like in terms of single- and multi-node setups. The main question I am trying to answer for myself is "Do we need to distinguish between the operation mode at API endpoints"? >From what I can see in

Re: [JENKINS] Solr » Solr-Lint-main - Build # 97 - Still Failing!

-Dtests.haltonfailure=false -Dtests.badapples=false --continue precommit > check -x test > > This explicitly disables tests so I don't expect any tests to run. I would > guess that the admin UI stuff is just hooked up to a different part of the > lifecycle. > > Kevin Risden >

Re: [JENKINS] Solr » Solr-Lint-main - Build # 97 - Still Failing!

Thanks for pinging, The issue is caused by the UI tests for the browser builds. In the gradle configuration of the ui module I explicitly chose to run the tests on a headless chrome browser, but that was just a wild guess. Since the checks passed on the PR, I believed that would be sufficient, but

Re: [DISCUSS] SIP-16: Polish and Prepare v2 APIs for v1 Deprecation

I am very pleased by the progress we achieved in this topic so far, and I would like to add some input from the consumers' perspective. With the start of the new Admin UI development (SIP-7), we now have an additional source for evaluating the v2 API and polish it based on additional scenarios.

Re: SIP-7: Merging the new Admin UI (experimental)

Since there were no additional change requests nor any objections, following the principle of lazy consensus, I will move forward and merge the changes. Look out for new Admin UI tickets in the next few days if you are interested in joining the development of the new UI. :)

Re: SIP-7: Merging the new Admin UI (experimental)

e of us not yet on Solr 10 could still take advantage of it > on our desktops. Maybe this is what you were getting at in your last > paragraph. > > On Thu, Jan 30, 2025 at 2:01 AM Christos Malliaridis < > c.malliari...@gmail.com> wrote: > > > Hello everyone, &

SIP-7: Merging the new Admin UI (experimental)

Hello everyone, The PR with an experimental, new Admin UI implementation that introduces a WebAssembly app and a standalone JVM client for Solr's UI overhaul has been out for a while. After resolving multiple TODOs, it is time to finalize and merge the changes, so that we can start adding more fu

Re: Changing the way we lock dependencies

Hello again, I just wanted to let you know that the PR #2925 has been merged into main. If you have any branch that includes changes in the dependency tree, remember to pull the latest changes from main and run "./gradlew resolveAndLockAll --write-locks" to update the lockfiles accordingly. In

Re: Changing the way we lock dependencies

o say I really appreciate the detailed discussion of the > benefits and tradeoffs here. Very helpful for those of us without much > context on the gradle stuff. > > Best, > > Jason > > On Tue, Jan 14, 2025 at 12:04 PM Christos Malliaridis > wrote: > > > >

Changing the way we lock dependencies

Hello everyone, I would like to merge https://github.com/apache/solr/pull/2925 next week, after doing some small cleanups. The PR improves the way our dependencies are resolved by introducing a platform module that automatically adds all our dependencies from our version catalog (gradle/libs.vers

Re: Eclipse support

move the generated ones to a "v2" sub-package or > something similar. I'd hate to confuse the user experience just to > fix a quirky IDE, but if it unblocks devs it's prob worth it. > > On Sun, Jan 12, 2025 at 11:30 AM Christos Malliaridis > wrote: > >

Re: Eclipse support

problem is > > that a package by the same name also exists ( > > org.apache.solr.client.solrj.request). It would've been ideal if the > > generated sources were to be in a package of their own, then I could've > > easily added it as a source dir in Eclipse. > >

Re: Eclipse support

Perhaps the latest "breaking" change introduced in v10 / main was related to the migration to version catalogs (#2706)? It may not have been tested properly and therefore may have broken the eclipse environment. Could you check if reverting the "wrapping" (line 24 in gradle/ide/eclipse.gradle) of

Re: v2 COLLECTIONPROP API - HK2 service reification failed for [org.apache.solr.handler.admin.api.CollectionProperty] with an exception

> Maybe should be in "bats" actually. Before adding more tests to bats we should probably migrate to an OS-independent test framework. The missing coverage for Windows is taking its toll. On Thu, Jan 9, 2025 at 2:29 PM David Smiley wrote: > Definitely +1 to a smoke test (just look for non-fail

Re: Welcome Pierre Salagnac as Solr Committer!

Welcome Pierre, looking forward to working with you. :) On Mon, Dec 9, 2024 at 10:23 AM Pierre Salagnac wrote: > Thank you so much everyone! > > I am very excited to be invited to join the community as a committer. > > I've been working with Solr for 10 years now, my first experience was with >

Re: SOLR-17531: Updating GC Options

I am planning to merge https://github.com/apache/solr/pull/2815 in the next days, so that I can address related issues next. On 2024/11/07 16:51:58 Christos Malliaridis wrote: > With the recent updates in the CLI scripts and JDK version, there are a few > cleanups and optimizations possi

Re: CHANGES.txt, process improvement solicitation

The changes.txt file confuses me a lot and I would love to see some improvements there. It is not clear to me at the moment of the PR creation / merge which version will be next to add the change entry to. Using a tool like the one Jan proposed makes sense to me and would likely solve the issues

Re: branch_9_8 created

SOLR-17559 has been resolved and merged into all branches including 9.8. I was also keeping track of SOLR-17551, which was resolved via another ticket automatically (see comments). Is it worth a CHANGES.txt entry in 9.8, or are the issue comments sufficient? On 2024/12/13 16:35:24 Christos

Re: branch_9_8 created

I just filed an issue where Solr cannot be started with examples on Windows. See SOLR-17595 for details. I believe that should be fixed before releasing, so I marked it as blocker. I will try to address the issue this weekend, but cannot guarantee to find the time. If anyone else has a Windows

Re: Admin UI Review Meeting - Feedback Requested

I want to thank everyone who participated in the review meeting. All the feedback that was shared and discussed was very valuable. I have documented the discussed topics in our meeting notes (not sure if this would be the right place), so that anyone who is interested can have a look. I hope I

Re: Admin UI Review Meeting - Feedback Requested

Hello everyone, Due to the public holiday on November 28, 2024, and considering the requested availability, the Admin UI Review meeting is scheduled for *November 27, 2024, at 17:00 UTC*. You can join the meeting via the following link: https://calendar.app.google/78iAM7aPuH4WzACG6 Please review

Admin UI Review Meeting - Feedback Requested

Dear Solr-Community, As part of the Admin UI migration (SIP-7 ), we are also embarking on a full redesign of the interface. The initial designs for the new Admin UI have been published and are available for review at th

Re: Introducing Gradle Version Catalogs

The current bot would require some configuration changes to get it running again, as renovate relies on palantirs plugin for updating lock files, and I believe it uses "gradlew --write-locks" to update the file. This would not work anymore. The bot already runs a custom task for including "grad

Re: Introducing Gradle Version Catalogs

This is the last call for SOLR-17406 / https://github.com/apache/solr/pull/2706. All matters have been resolved and the changes will be merged soon if there are no objections. If you are having any open PRs that make any changes in gradle files, I'd recommend to wait before merging. If you add

Re: Introducing Gradle Version Catalogs

Bringing up this topic again as the PR https://github.com/apache/solr/pull/2706 is ready for another review round. Since it changes the way dependencies are managed, it would be great if we can get more eyes on the PR before merging it. This is also the last "blocker" of the POC for the new Adm

SOLR-17531: Updating GC Options

With the recent updates in the CLI scripts and JDK version, there are a few cleanups and optimizations possible in the GC parameters that are passed to the Solr instance. Since I am not experienced enough in GC stuff, I'd like some experts to review https://github.com/apache/solr/pull/2815. There

Re: [DISCUSS] Support of time zone mappings in ParseDateFieldUpdateProcessorFactory

first. > > I don't recommend adding a feature that nobody actually needs/asked-for. > > On Tue, Nov 5, 2024 at 5:16 PM Christos Malliaridis < > c.malliari...@gmail.com> > wrote: > > > Looking into the recent JENKINS jobs, one of the failing tests is > >

[DISCUSS] Support of time zone mappings in ParseDateFieldUpdateProcessorFactory

Looking into the recent JENKINS jobs, one of the failing tests is java.time.format.DateTimeParseException: Text 'Thu Nov 13 04:35:51 AKST 2008' could not be parsed at index 20 The root cause of this failing test seems to be related to JDK 23 (and Windows?) and has some history from JDK 8/9 accord

Re: HELP wanted: Dependency upgrades

Thanks for the answers. I'm looking forward to the release then, to see the process cycle complete. :) I would love to use the cherry-pick.sh for also pushing to the branch, but it fails on my machine / Windows when it tries to run the tests (probably some gradlew / gradlew.bat issues). I didn't h

Re: HELP wanted: Dependency upgrades

Thanks for the responses David, this helps me to improve the documentation for this process. I am proceeding with the dependency updates and so far it seems most of the time to be straight forward, with a question popping up every now and then. The only challenge so far has been the identificati

Re: [PR] Bump up Java version to 21 [solr]

dition, where it is much less > > helpful and entirely fails to run: > > > > Invalid Gradle JDK configuration found. Open Gradle Settings > > > > On Sat, Oct 26, 2024 at 10:30 AM Christos Malliaridis < > > malliari...@apache.org> wrote: > > > > >

Re: HELP wanted: Dependency upgrades

t; > > they will conduct an upgrade to a new release, or how to prepare for it > > > will want to pay attention to some dependencies. Solrbot probably has > > less > > > use for the credit and reputation from contributing to Solr than the > > > developer :). >

Re: HELP wanted: Dependency upgrades

rary and the committer, and the PR/JIRA as applicable. Solrbot's > involvement is irrelevant to users, so something like: SOLR-15609: Upgrade > log4j to 2.14.1 (hossman) > > On Thu, Oct 24, 2024 at 10:16 AM Christos Malliaridis < > malliari...@apache.org> wrote: > >

Re: [PR] Bump up Java version to 21 [solr]

So after a bit of trying around, I am facing the error message on Mac and Windows with the latest stable IDE version of IntelliJ. The error message is returned at the end of every ./gradlew check and is probably coming from the IDE and not Gradle itself. Just for reference what the message looks

Re: HELP wanted: Dependency upgrades

I assume waiting any longer will not make much sense, so I am going forward and start merging at least the "easy" dependency updates. I will also look into documenting any experience / process at the end, so that others will have it easier to address dependency updates in the future. Keep an ey

Re: [PR] Bump up Java version to 21 [solr]

lchain, I will provide details in a separate email. > > -- Sanjay > > > > > On Thu, Oct 24, 2024 at 9:58 PM Christos Malliaridis > wrote: > > > Just noticed, Gradle 8.4 does not support JDK 21 (only up to 20). So the >

Re: [PR] Bump up Java version to 21 [solr]

Just noticed, Gradle 8.4 does not support JDK 21 (only up to 20). So the last part about updating Gradle JVM in the IDE may cause other issues. I guess upgrading Gradle is one of the next steps. :) - To unsubscribe, e-mail: dev-

Re: [PR] Bump up Java version to 21 [solr]

I had the same issue on Windows. I updated the JAVA_HOME and PATH to point to JDK 21. Since I have multiple JDKs installed, the order in PATH is important, as only the first path to a JDK directory is taken into account by IntelliJ. I also updated the Gradle JVM under Build, Execution, Deploymen

Re: HELP wanted: Dependency upgrades

I got a few questions before interacting with the Solrbot PRs, because I haven't done that before. - When are the CHANGES entries added, and when not? Is it just "if Solrbot created the PR, then it will be added automatically during next release"? - In case no additional actions are necessary, w

Re: [DISCUSS] Automated bin/solr.cmd script testing for Windows

Funny, I was currently looking for a solution to make the bats tests run on Windows. I would probably prefer a JUnit approach that executes the commands with ProcessBuilder and avoid that way additional dependencies and test frameworks. We would also avoid having duplicate tests. I considered

Re: Overlapping arguments (SOLR-17383)

With the last merge of URL options we will be able to proceed and further simplify the CLI classes, especially in the URL composition that has been quite error prone. I'd like to share the last migration that affects the -i option. For that you can have a look in the proposed changes of https:

Re: Welcome Christos Malliaridis as Solr Committer

very first day, and this experience encouraged me to look into further contributions. I will try my best to share and pass down the same sense of warmth and encouragement to others as I continue contributing to the team and project. With sincere thanks, Christos Malliaridis

Re: HELP wanted: Dependency upgrades

The main blocker based on the PR comments seems to be the JDK version in Solr that is too low to upgrade some of the dependencies. If Solr will use JDK 21 in v10.0, it shouldn't be a problem updating these dependencies before v10. I could create a JIRA ticket with subtasks for each dependency upda

Re: Overlapping arguments (SOLR-17383)

Now that we are almost finished with the cleanup of overlapping flags, we may consider merging some options that serve the same purpose, so that users don't have to remember multiple options based on the tool / argument they are using. I'd like to gather input from all on this topic, since it has

Re: Overlapping arguments (SOLR-17383)

We are almost done addressing all the overlapping issues I wanted to cover in this series and we already solved multiple conflicts. I would like to add the next resolutions in this message. Right now, the common entrypoint for the tools is bin/solr(.cmd). This includes the AssertTool, which uses s

New Solr Admin UI - POC Presentation

nvite link: https://calendar.app.google/aR49NJ72MfdwKfcBA Read more about this Solr improvement proposal (SIP-7) at https://cwiki.apache.org/confluence/display/SOLR/SIP-7+Updated+Solr+Admin+UI . Best regards, Christos Malliaridis

Re: Overlapping arguments (SOLR-17383)

I am happy with the current solution of your PR Eric, thanks. I would like to continue with two more flags that may cause confusion or in future additional conflicts. These flags are -f and -s. They are used multiple times in multiple tools for different options or similar options with different n

Re: SIP-7 New Admin UI

Thanks Jason for updating the SIP-7 page. I think further updates to the page will follow soon with more information. I have prepared a presentation in favor of the POC ( https://github.com/apache/solr/pull/2605) where I go through the basic theory and show how a component with Kotlin and Compose

Re: Overlapping arguments (SOLR-17383)

> >> > >> Maybe both? Meaning, if "-v" is provided, start Solr in verbose mode > and > >> print the version number first. > >> > >> On Sun, Sep 8, 2024 at 2:34 PM Christos Malliaridis < > >> c.malliari...@gmail.com> > >

Re: Introducing Gradle Version Catalogs

I've now revised the initial PR (https://github.com/apache/solr/pull/2646) and created a clean PR with the changes and version conflict resolution. See for that https://github.com/apache/solr/pull/2706. The new PR does not include dependency updates like the initial PR. Right now, the constraints

Re: Overlapping arguments (SOLR-17383)

t; Why keep "-v" and "-version" around? I'd much rather keep the very > widely-used "-v"="--verbose". > > Only supporting "bin/solr version" makes much more sense to me. And I'm not > even particularly worried about back com

Re: Overlapping arguments (SOLR-17383)

e the right naming from now on. A nice website with useful information that Eric showed me is *https://clig.dev/. On Fri, Aug 30, 2024 at 7:51 PM Christos Malliaridis < c.malliari...@gmail.com> wrote: > Continuing with the next conflict, > > We use -p mainly for the port argument and

Re: Overlapping arguments (SOLR-17383)

eTool and --params in PostTool are used for passing parameters, we can consider in another discussion to deprecate and replace --param with --params. On Tue, Aug 27, 2024 at 11:17 PM Christos Malliaridis < c.malliari...@gmail.com> wrote: > Hello everyone, > > In order to start res

Re: Overlapping arguments (SOLR-17383)

/browse/SOLR-17423, which proposes the deprecation of -h for hostname in the context of RunExampleTool, and the removal of it in future major releases (10.0 ongoing). If there are any objections, please let us know. Best, Christos On Fri, Jul 26, 2024 at 9:36 PM Christos Malliaridis < c.malli

Re: Introducing Gradle Version Catalogs

> What palantir-consistent-versions did (always taking the ceiling) is easier but less transparent, I am for transparency too, I had enough troubleshooting sessions for fixing something that I couldn't see. What I also found is that there are some difficulties in keeping the constraints clean the

Re: Introducing Gradle Version Catalogs

I worked on the PR and solved the version conflicts now. I considered removing the plugin, as you proposed, but I ended up using it instead, because its functionality is still useful in my opinion. I am just not very happy with the repetitive constraints and the need to include transitive dependenc

Re: Introducing Gradle Version Catalogs

I've created SOLR-17406 and PR 2646 so that we have something to work with. We probably have more than enough time to finish this migration before Solr 10 is released.

Re: Introducing Gradle Version Catalogs

> It's not just that. Indeed, I saw that you also added spotless and tidy to the gradle build files and provided a gradle plugin for the dependency checks. I definitely and unintentionally talked down your work in that PR, sorry for that. I started a couple weeks ago a migration without knowing t

Re: Updating Dependencies - Apache Tika

find a suitable Java client for Tika > Server REST API. Perhaps that exists now? > > Jan Høydahl > > > 12. aug. 2024 kl. 16:20 skrev Christos Malliaridis < > c.malliari...@gmail.com>: > > > > Hello everyone, > > > > I've been looking into the d

Introducing Gradle Version Catalogs

In the Lucene project there was a couple weeks ago a migration to version catalogs (see PR #13484 ). I'd like to follow the same approach in Solr, as it would allow us to sync some of the dependencies and keep all versions in one file. If this is some

Updating Dependencies - Apache Tika

Hello everyone, I've been looking into the dependencies of the project and thought that we could update a couple of them, together with their license files (wherever necessary). I tried to start with Apache Tika and upgrade it from 1.28.5 to 2.9.2, which is a huge step due to some restructuring o

Re: SIP-7 New Admin UI

de ready to look at. It might be a little > easier for folks to review and ask questions about the code if you use > it to create a "Draft" PR from your fork/branch - is that something > you'd be willing to do? > > Jason > > On Sun, Jul 28, 2024 at 1:24 PM Christos

Re: SIP-7 New Admin UI

With the input and feedback from the virtual meetup I'd like to wrap up the current progress with a couple of references: *Figma Design* I have created a Figma design (WIP) that

Overlapping arguments (SOLR-17383)

Hello devs, I would like to get some attention on overlapping arguments that I have found and documented in SOLR-17383 . This was one of my "bad experiences" when I started working with Solr, so I think it may be more important than I thought. Wit

Re: Retrieval of License and Notice files for /solr/licenses

t often > not. > > Dawid > > On Fri, Jul 19, 2024 at 12:37 AM Christos Malliaridis < > c.malliari...@gmail.com> wrote: > > > Hello devs, > > > > I was working on a migration to versions catalog to learn more about the > > gradle configurations and I

Retrieval of License and Notice files for /solr/licenses

Hello devs, I was working on a migration to versions catalog to learn more about the gradle configurations and I am now following the changes from https://github.com/apache/lucene/pull/13484 (thanks David for the reference). I wanted to figure out how the files in /solr/licenses are generated / c

Re: [DISCUSS] Community Virtual Meetup, July 2024

I'll try to participate too, the time and date would be great and easier for me to join. Thanks for organizing this time again. :) - Christos On Thu, 18 Jul 2024, 16:04 Jason Gerlowski, wrote: > Alright, > > I'm happy to organize this month. I'll create the meeting notes pages > and links sh

Re: SIP-7 New Admin UI

manage to partition the elephant, pick a few tasks further down the > road. > > I do Kotlin in day job, and it is an absolute joy to work with. Not hard > at all, so to committers fearing a "new" language, it is actually not that > different, just skip the "new" keywork

Re: SIP-7 New Admin UI

im to fill in > new gaps. Then, if you get traction there, as we migrate to V2 apis for > example, maybe that code gets moved into the new tool? > > > > > On Jul 15, 2024, at 3:49 PM, Christos Malliaridis < > c.malliari...@gmail.com> wrote: > > > > Thanks

Re: SIP-7 New Admin UI

e: > An admin UI can definitely be plugged in. Here is one: > https://github.com/yasa-org/yasa > And you would not be the first to consider a desktop client. There is > one of those too: https://solr.search-navigator.org/ > > On Tue, Jul 9, 2024 at 9:37 PM Christos Malliaridis

Re: IntelliJ not working with latest main

> > ListCollectionsResponse. > > > > Any ideas, please? > > > > If I rollback to the commit before the following one, it works fine: > > > > commit 461955f00118c69d06f50e72addeff12c8dd8169 > > Author: Christos Malliaridis > > Date: Tue Jun 11 18:15:01 2024

Re: Vex file 404

Apparently the file is available at https://solr.staged.apache.org/solr.vex.json, but not the production / official site. Looking into the commit history, the changes where VEX was re-enabled are not merged yet in

Re: SIP-7 New Admin UI

oncern with putting code in the main repo is that > it's > > > > > pretty far from the (current) PMC's/community's wheelhouse to > > > > > maintain. I definitely share that concern. But IMO we're already > > > > > sortof at

SIP-7 New Admin UI

Hello everyone, In regards to SIP-7 and SIP-10 I would like to add my perspective and address the current concerns about imple