Happy to hear that. :D Feel free to add me as reviewer If you need some eyes on kotlin code.
About the indentation, I think back then I went with Kotlin default styleguides, but feel free to update that and run the linter. I have no strong preferences here, I just find it sometimes more readable with 4 spaces. On Fri, Jul 10, 2026, 22:17 David Smiley <[email protected]> wrote: > Note: I have a PR that will introduce a Kotlin buld file (outside of UI) > and I reviewed a PR today that will do likewise for another. I found that > choosing Kotlin prevented an error that would have occurred if I had chosen > Groovy instead. I like Kotlin. > > I don't like that our .editorconfig says kotlin build files get a 4-space > indent, which is broadly inconsistent with our text source files. But this > is minor and we can change it. > > On Sat, Feb 14, 2026 at 3:52 PM Christos Malliaridis < > [email protected]> > wrote: > > > This is the discussion I am seeking, thanks a lot David and Gus. I hope > it > > will help us evaluate the proposal I am making. > > > > > Gradle has excellent support for it, as does IntelliJ > > > > This was the main trigger of this proposal. I miss the documentation and > > proper highlighting in IntelliJ for the build files that I am looking > into > > every now and then. > > > > > I don't want to spend time learning new things about the build. > > > > I understand. The time needed to learn a new language should not be taken > > lightly. I believe that the Kotlin DSL is syntactically very similar to > > Groovy with only small differences, so it should be very easy to read and > > learn. An example what it means to migrate can be found in [4], where I > > migrate the build.gradle and settings.gradle to build.gradle.kts and > > settings.gradle.kts. If you use IntelliJ and checkout the branch, you > will > > see the difference in the IDE support I wish for. > > > > With "reduce the issues some people face" I am referring to my experience > > with all the python scripts that we have, that are not working on my > > machine (Windows) and also didn't work out-of-the-box on my Mac. As you > may > > know, Windows users come with 2+1+1 terminals, the CMD, powershell, Git > > Bash (since you usually install git with a bash) and WSL. All have > > different behavior when it comes to path resolution or environment > > variables in scripts and tools that are expected to be installed and > > configured on the machine. One of the tools used in our smoke tester > script > > (gpg) had even different options on Windows. > > > > > That's a nice list but can you provide examples of these things in > *our* > > build? > > > > I believe there are enough cases where the topics I mention were an > issue: > > > > - Compatibility with operating systems like Windows is a problem which > was > > discussed recently > > - With Kotlin I had positive experience writing OS-independent > > build files that interacted with files and file paths. One example > related > > to our project would be [4] > > - Our Solr scripts (bin/solr and bin/solr.cmd) for running and launching > > solr had and still have bugs and challenges, mainly because of the > > platform-specific dependency (see for example [7] and [8]) > > - Some time ago I created a CLI sub-module written in Kotlin [3] that > > could replace our solr scripts (bin/solr and bin/solr.cmd). It would add > > testability for all operating systems and without the need of an > additional > > testing framework (see also [6]). Code duplication would also be > addressed > > this way. > > - [1] would be an example for the environment constraints that are > causing > > issues in our CI/CD > > - I believe without enough knowledge that some pre-Lucene-Solr-split > stuff > > is lying around in the build files, perhaps [9] and [10]? > > - Another benefit of using Kotlin would be to have more people getting > > familiar with it, so more people could contribute to the new UI of Solr > in > > the future > > > > Most of the problems are solvable, yes, and they are usually > > platform-specific. But the platform constraints we currently have give > new > > devs a difficult start. So I believe we should reduce them as much as > > possible. After all, I believe we don't want the project to limit > > the platforms developers are using. > > > > > "introduce issues and learning curve for people who have been working > > with groovy/gradle builds for a decade > > > > Yes, that is indeed a topic worth discussing. The goal is not to > introduce > > new issues by migrating to Kotlin. And a learning phase is inevitable > when > > switching languages, obviously. But I believe Kotlin DSL has done a > > great job in keeping a steep learning curve. See gradle files from [4] as > > an example. > > > > If we manage to replace python scripts with Kotlin DSL, we would not need > > python in the environment. A resolution of a recent issue seems to be > > related to that [1]. There is obviously no perfect solution, and always > > developer preferences that influence these decisions. > > > > Gradle Builds switched to Kotlin DSL some time ago, and the reasons are > > well-described in this article [2]. I believe proper IDE support is one > of > > the main improvements I am looking for, as I had some hard time writing > > working Groovy configurations with a trial-and-error approach. > > > > > And testability only (maybe) applies to scripts not the build. > > > > For build files it depends. I have seen a lot of logic in our build files > > that, if refactored, could include some tests as well. The question is do > > we need tests for these parts? > > > > > -0 for any build migration of any sort until there are clear problems > in > > *our* > > build that actually will be solved via kotlin > > > > For that I may not know the gradle builds well enough. So except the IDE > > support and current complexity of our build files that costs me more time > > than necessary whenever I touch them, I don't have good reasons prepared. > > So I'd like to forward this request to others, maybe there are people out > > there that face some problems worth mentioning now? > > > > Without being able to support my opinion, I believe our build files are > > more complicated than necessary due to the history Solr and Lucene had > > together. > > > > > [...] and also until the most active current maintainers of the build > say > > they like the idea > > > > If we plan to proceed with this topic, initiating a vote would be > > worthwhile. > > > > > +0, interested for scripts but not +1 until demonstrated.... > > > > I think [3] and [4] could be candidates for this? I am willing to > migrate a > > script of your choice too if you have a preference. > > > > > part of the script's job is to *remain readable and tweakable*, so > > "compiled scripts" that have to be recompiled after editing are a solid > -1 > > for me > > > > I believe Kotlin scripting [5] would be possible, but likely not > > recommended due to its current state. May I ask why compiled scripts > would > > be a problem? I am considering Gradle tasks for replacing our custom > > scripts. They would still be executed through a single ./gradlew call. > Not > > sure if that is a deal-breaker for some cases I am not aware of? > > > > > and therefore, we do need to justify the added environmental dependency > > (including version!) > > > > This is already the case for python scripts, if I am not mistaken. On the > > other hand, Kotlin scripts (or at least Gradle Kotlin DSL) would be > > maintained by our current dependency management system and resolution, so > > no additional dependencies that require special treatment are added. > > > > Thanks again for your input. I hope I could address some of your > concerns. > > > > Best, > > Christos > > > > [1] https://lists.apache.org/thread/ffmjb37toj9b80dg58l4gy62hpwptdr5 > > [2] > > > https://blog.gradle.org/kotlin-dsl-is-now-the-default-for-new-gradle-builds > > [3] https://github.com/malliaridis/solr/tree/feature/cli-module > > [4] > > > > > https://github.com/apache/solr/tree/feature/migrate-renovate-changelog-script > > [5] https://kotlinlang.org/docs/custom-script-deps-tutorial.html > > [6] https://github.com/apache/solr/pull/3810 > > [7] https://github.com/apache/solr/pull/4127 > > [8] https://github.com/apache/solr/pull/4075 > > [9] > > > > > https://github.com/apache/solr/blob/main/gradle/lucene-dev/lucene-dev-repo-composite.gradle > > [10] > > > > > https://github.com/apache/solr/blob/01fc236c70732319f0d688e0231f76c64744adf6/build.gradle#L115 > > > > > > On Sat, Feb 14, 2026 at 8:23 PM Gus Heck <[email protected]> wrote: > > > > > *TLDR; I tend to wish the build files would stand as still as possible > > so I > > > can focus on the rest of the application. * > > > > > > I don't want to spend time learning new things about the build. If I > > > haven't contributed for a while, the #1 impediment to re-starting is > > > dealing with whatever changed about the build. The less it changes, the > > > better. This doesn't mean we shouldn't improve it, just that I think we > > > should not make developer-visible changes lightly. > > > > > > That's a nice list but can you provide examples of these things in > *our* > > > build? Your list sounds generic. When have these things held us back? > Not > > > wanting to learn groovy is similar to not wanting to learn kotlin > unless > > we > > > establish that a significant majority (much greater than 50%) of the > > > community is (already!) familiar with kotlin and unfamiliar with > groovy. > > > > > > Let me note that > > > - "reduce the issues some people face" is going to also be paired with > > > "introduce issues and learning curve for people who have been working > > with > > > groovy/gradle builds for a decade" and > > > - you mean "improve syntax highlighting" because there is (buggy) > > > highlighting and completion for groovy in intellij... > > > - And testability only (maybe) applies to scripts not the build. > > > > > > Not interested in changing just because language X is more popular > than Y > > > unless it's overwheliming preference in our community This was true of > > > Groovy vs XML when we did the ant migration... XML was at the nadir of > > its > > > popularity, and people were rabidly attacking XML on sight at that > time. > > > > > > However, XML was NOT a reason I supported the ant to gradle migration, > > the > > > ability to script cleanly, and the tightly integrated dependency > > resolution > > > (without complicated additions like Ivy) were clear wins there. Ant's > > > original stance was "declarative only, write tasks in java for > > programatic > > > stuff", but the reality is even though ant tasks were fabulously easy > to > > > write, few people wanted to do it. The build for the build problem is > > > irritating and we still have it in buildSrc builds in gradle. If using > > > kotlin somehow eliminates the prebuild build that we have to do before > > > configure phase runs, then THAT IS a win. (I doubt it does though). > > > > > > -0 for any build migration of any sort until there are clear problems > in > > > *our* build that actually will be solved via kotlin (and also until the > > > most active current maintainers of the build say they like the idea) > > > > > > I guess I have the opposite affinity for the two halves (build vs > script) > > > from David since the question of scripting actually sounds like it > > solves a > > > problem to me. If kotlin is good at general scripting (I haven't used > it > > > much) that, because then we *might* be able to support both windows and > > > posix environments with a single script (but I also strongly suspect > > there > > > are devils in the details there) If kotlin can improve support for > > widows, > > > that solves a problem we do actually face. > > > > > > +0, interested for scripts but not +1 until demonstrated.... > > > > > > However, IMHO, part of the script's job is to *remain readable and > > > tweakable*, so "compiled scripts" that have to be recompiled after > > editing > > > are a solid -1 for me, and therefore, we do need to justify the added > > > environmental dependency (including version!) or include our preferred > > > version of kotlin in the distribution (I beleive it is ASL 2.0 so > perhaps > > > possible), and then shipping it will place boundaries on our JVM > > > compatibility.... > > > > > > -Gus > > > > > > On Fri, Feb 13, 2026 at 10:07 PM David Smiley <[email protected]> > > wrote: > > > > > > > I'm +1 on switching from Groovy to Kotlin in our **Gradle build > > files**. > > > > Gradle has excellent support for it, as does IntelliJ, and I'm rather > > > fond > > > > of Kotlin, having used it once. I look forward to editing these > files > > > with > > > > better IDE assisted type awareness and less magic/voodoo. > > > > > > > > But I'm unsure about the broader scope you speak of. > > > > > > > > On Fri, Feb 13, 2026 at 8:02 PM Christos Malliaridis < > > > > [email protected]> > > > > wrote: > > > > > > > > > Hello everyone, > > > > > > > > > > I'd like to discuss here and in our meetup on Wednesday our current > > > state > > > > > of our build files and scripts. I'd like to propose a possible > > > migration > > > > > that will add many benefits, listed below. > > > > > > > > > > The migration is about replacing all our python scripts and groovy > > > build > > > > > files with Gradle Kotlin DSL. This would > > > > > - reduce the issues some people face with our scripts (like me) > > > > > - improve the compatibility with operating systems > > > > > - reduce the dependencies to environment constraints > > > > > - add testability to these files > > > > > - cleans up old stuff > > > > > - add syntax highlighting, IDE support and code completion > > > > > > > > > > Therefore, besides this discussion here, I'd also appreciate your > > > > > participation in our meetup next week. > > > > > > > > > > What are your thoughts on this? We are already using Kotlin for the > > new > > > > UI, > > > > > so why not use it more so folks get more familiar with it? > > > > > > > > > > Best, > > > > > ChristoS > > > > > > > > > > > > > > > > > > -- > > > http://www.needhamsoftware.com (work) > > > https://a.co/d/b2sZLD9 (my fantasy fiction book) > > > > > >
