Note that the generation is now done through a few velocity templates. A single template is used to generate all the model classes: https://github.com/apache/maven/blob/master/src/mdo/model.vm That one is used to generate the 7 models we use (model, extensions, metadata, plugin, lifecycle, settings and toolchains).
A single change to this file will allow experimenting with records and whatever we want. Modello is mostly used as a *model*, but the only modello generators we use are xdoc and xsd. I'm fine if people want to replace modello with a different generator, though I think the switch to velocity templates has solved all problems, at least those I've been experiencing. Le mar. 25 mars 2025 à 13:01, Elliotte Rusty Harold <elh...@ibiblio.org> a écrit : > Really what we need to do is eliminate modello. It's a failed effort > from back in the 2000s when people who are no longer around thought > they were building a general purpose framework for Java apps instead > of a build tool and repository system. It makes our build and > development far more complex than it would be if we used plain old > Java classes checked into the source repo. I've tried to fix problems > before that wound up inside Modello somewhere, and it's just not worth > it. I wouldn't invest further effort there on anything other than > ripping it out. Once Modello is gone, we can take another look at > where Maven is, and see if record classes make sense. > > On Tue, Mar 25, 2025 at 11:53 AM Martin Desruisseaux > <martin.desruisse...@geomatys.com> wrote: > > > > Hello > > > > The `org.apache.maven.api.model` package of Maven 4 contains classes > > generated automatically from the `maven.mdo` file [1], which describes > > the POM. The generated classes are similar to Java records > > (unmodifiable, straightforward getter methods, etc.). However, they have > > a lot of boilerplate that could delegated to Java record: > > > > * All the getter methods > > * Implementation of equals, hashCode and toString > > * Builder and `with` method for each property (could be replaced by > > JEP 468 [2] - in preview) > > > > Records also have facilities that we cannot reproduce, such as record > > pattern [3]. Should we migrate, or prepare migration, of part of the > > Maven API to record? > > > > A first limitation is that a record cannot extend another class or > > record. For the `org.apache.maven.api.model` package, we could turn the > > base classes `ModelBase`, `BuildBase`, `RepositoryBase`, `Repository`, > > `PatternSet` and `FileSet` into interfaces and accept to repeat > > properties in records that implement the same interfaces. > > > > Another limitation is that records benefits provided by JEP 440 and 468 > > are not available in Java 17 (the version required by Maven). We could > > keep the generation of the `with` methods for now with a warning saying > > that they may be removed in a future version. We would still have the > > other benefits and be prepared for this evolution. > > > > Any though? > > > > Martin > > > > [1] > https://github.com/apache/maven/blob/master/api/maven-api-model/src/main/mdo/maven.mdo > > [2]https://openjdk.org/jeps/468 > > [3]https://openjdk.org/jeps/440 > > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- ------------------------ Guillaume Nodet
