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
