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) > > >
