Polyglot status?

[OndraZizka]

Hi all! I have issues introducing Maven to my colleagues, because of the XML.
Honestly, I was showcasing Quarkus, and half of the questions were around "if it must be in Maven". People don't even dive into how Maven works and ignore it because of how ugly ugly the XML appears to them.

I used the Maven Polyglot by Takari a couple of times. YAML is fine but still I sometimes need to write stuff in a peculiar way or split into tiny modules to reduce the repetitiveness of the code. (Which may be the point - I feel Maven pushing strongly to split into project modules for e.g. ordering of actions, and have artifacts as intermediate steps. Unlike Gradle, where people tend to cram all build logic into one script.)

Then I saw Maven Polyglot Kotlin:
https://lnkd.in/dSKZUJXd
and to me, that seems to be the way to go to appeal to people which would not touch XML, and are used to Gradle. Maven POMs in Kotlin would reduce the unwanted freedom/complexity Gradle gives (and ends up being misused most of the time), but still give an effective syntax to express the build.

What is the plan for Maven 4 regarding Polyglot? Is there any commitment to keep Takari extensions working? Or anything new on the horizon? Thanks.

[cstamas]

Check out https://github.com/maveniverse/mason
Old Takari polyglot will work for Maven 3, but in Maven 4 things are changing. Also, am unsure would there be a polyglot solution that allows passage between Maven 3 and Maven 4 (having it buildable with both major versions).

[gnodet]

I don't really like the idea of having the POM not being declarative, and I'm not convinced yet by the benefits it would bring.

Fwiw, to avoid repeating config across modules, Mixins may be a better way.

[OndraZizka]

@gnodet , the Polyglot doesn't make POM not declarative. It is mostly just different syntax.

For the Kotlin mentioned above, again, it is declarative, resulting into the same POM object.

Trust me, I would be the last one to suggest to go the Gradle way (random custom scripts invoking internal classes etc).

It's just that you can do some shortcuts like

Dependencies(
   "foo,bar".split(",").map { Dependency("<groupId>:<artifactIdPrefix>-$it:<version>") }
)

(I Just made up this syntax. The example is not showing the value it brings, rather just the approach.)

The idea is, that humans may express more naturally and briefly in languages, and the tools (IDEs etc) still can get a comprehensive, and deterministic POM, with little effort and transparently - they get POM regardless of the language the POM is written in.

A classical example of where it could bring value is the verbosity of plugins executions. Each execution, despite almost the same as the others, especially when used within profiles, may take dozens of lines in standard XML formatting.

With Kotlin for instance, you can do:

val execution = Execution(id = ..., phase = ..., configuration = Configuration( emptyMap() ) )

val paths = listOf("subpath1", "subpath2")

Plugin( groupId = ...,  ..., 
    executions = paths.map { subpath ->
        execution.copy().apply { this.configuration["path"] = project.resourceDir.resolve(subpath) }
    }
)

In few lines, you may express a lot, while still declarative, and save hundreds of lines of XML.

[gnodet]

Yet, it cannot be read anymore as the POM becomes a code snippet that needs to be executed.
You also have no way to relate the object model to lines in the POM and it's becoming very hard to think about modifying the POM.
Tools such as dependabot won't be easy to adapt to such languages.

Anyway, it should be quite simple to port to Maven 4, as it's really just a simple interface to implement, so give it a try !