Polyglot for Maven VS Gradle

And you don't even need to use XML with Polyglot Maven

https://github.com/takari/polyglot-maven

If you prefer the shorter alternative, you might want to use the Polyglot XML extension https://github.com/takari/polyglot-maven/tree/master/polyglot-xml

Here you go: https://github.com/takari/polyglot-maven

Fun fact, POM files can be in formats other than XML (although I have no idea if IJ would tolerate such shenanigans): https://github.com/takari/polyglot-maven/blob/polyglot-0.4.8/polyglot-yaml/src/test/resources/snakeyaml/pom.yaml

There is a certain argument to be made for user ergonomy. Many developers are drawn to Gradle and friends, or to work with polyglot Maven, because they support a more concise syntax. This is not necessarily a contradiction with Maven's Goals!

I wished they‘d finally embrace polyglot maven https://github.com/takari/polyglot-maven. pom.yaml rule the world.

It seems merely adding a file to the .mvn directory will do as you wish: https://github.com/takari/polyglot-maven#usage

I have avoided that road because it's one more thing that is a snowflake in the very area where I don't want to blazing trails. But I have personally tried their approach before and can confirm it does work as advertised. I can't recall if IJ lost its mind over pulling a stunt like that, but arguably if it did, then filing a YouTrack is an appropriate next step

A ("shared") build service is kind of like a singleton, in that when you register one in any project, it's available in all projects as a single instance. (This unfortunately turns out not to be true, in some cases, when using composite builds, but can be worked around.) An actual singleton (global static instance) doesn't work at all, for the record—try it if you want to lose some sanity. Anyway, use a build service whenever you need global mutable state in your build.

When using build tools like Maven or Gradle, you can configure environment variables in the build scripts or configuration files.

For large projects, purpose-made build tools such as Gradle and Maven are preferred for managing the directory structure since they introduce additional semantics for managing test code and other programming languages (among lots of other things). Most IDEs can integrate with these build tools easily. If you're just starting out though, I wouldn't worry too much about these, you can visit them later.

Project Build and Management: Apache Maven 3 (3.9.5), Gradle 8 (8.3)

No wonder this had been raised previously, https://github.com/gradle/gradle/issues/15383

Ktor, a powerful web framework built with Kotlin, offers a lightweight and flexible solution for building web applications. In this article, we will guide you through the process of creating a Ktor project manually using Gradle and SDKMAN!. By following the steps below, you'll have a basic Ktor project up and running in no time.

The details regarding the code compiling would vary from one project to another. For that project, it seems that it uses Gradle (a helper tool) for compiling. Check Gradle's documentation for more information.

At the moment, Java 20 is the latest version, but Java 17 is the latest LTS release. It's usually best to use an LTS release, because the latest releases won't be widely supported. And that's true of Gradle too. You're using Gradle 8.0, but not even the latest version of Gradle (8.2) fully supports Java 20. You'll have to wait for Gradle 8.3 to use Java 20.