Globally it looks good, the only minor detail I would make is that instead of inlining params in methods considered as API (extension points, the model reader for ex) I would use a "request" object so read(a, b) would become read(req) to enable use to make it evolving more reliably instead of relying on untyped and random options but that's a minor detail.
BTW, did you manage to validate the whole model graph is POJO friendly? Idea is to make it "mapper" friendly OOTB and not require a custom model reader more complex than new MyMapper().map(input, Model.class). Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 22 août 2023 à 09:36, Guillaume Nodet <gno...@apache.org> a écrit : > Hi everyone, > > I hope you guys have been able to rest a bit during the summer (for those > that are back to work already)... > > I've pushed a few important PRs in the past months and I'd really like to > get the discussion going around those. Those are major changes that I > think we should introduce in Maven 4 asap: > * Better support for alternative POM syntaxes > * Needed infrastructure to evolve the model > * POM mixins > * Support for XML entities / XInclude > > The first 3 changes are stacked onto each other. The first one is the > support for alternative POM syntaxes [2]. Note that no syntax is provided > by the PR, but an example extension is provided in the IT PR [3], the > reader being generated using the maven model and the IT's project is using > it [4]. The main idea is to provide an enhanced XML syntax if we want, as > it was discussed for the POM 5.0 [5]. > > The second one provides the ability to make evolution to the model without > breaking the maven ecosystem. The model has been stuck in 4.0.0 version > for 15 years or so, most of the things that would have required a change > have been delayed or worked around. The consumer POM that has been > introduced in Maven 4 is a first step, but I think we should go further. > Please read the details in the PR [6]. > > The third one is the support for POM mixins [7]. That one is still a > draft. Two ITs have been written to leverage mixins using GAV or as > relative paths [8]. This definitely needs some work, but the current state > definitely shows that it can be implemented and introduced in the next > alphas. > > The last one is a relatively small PR [9] which brings support for XML > entities and XInclude loaded from external files. All loaded files are > loaded using relative URLs (absolute URLs are rejected for security > reasons). The entities and xinclude bits are all inlined during the raw -> > consumer POM transformation so that they don't appear in repositories. I > wrote this PR as a possible alternative for mixins, that's the main reason > why I include it in this discussion. > > I'm not necessarily looking for in-depth reviews of the PRs, but at least > to find a consensus and general agreement on the way forward. > > Cheers, > Guillaume > > [2] https://github.com/apache/maven/pull/1197 > [3] > > https://github.com/apache/maven-integration-testing/pull/276/files#diff-ffb3dec529cab94ebf3c5830444275ad2b2e4826fe1df843454882efadd2446c > [4] > > https://github.com/apache/maven-integration-testing/pull/276/files#diff-8d7362e60d231ad8c5d4b7746873da2855d9cf1fd5aeeca9c143ed942bd94b38 > [5] > https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0 > [6] https://github.com/apache/maven/pull/1160 > [7] > > https://github.com/apache/maven/pull/1209/commits/211e27acd21a6cb8cee30ccd066499fc613a5c82 > [8] > > https://github.com/apache/maven-integration-testing/tree/b2642d74caae854051dc77acd19b972dfe66b1cd/core-it-suite/src/test/resources/mng-5102-mixins > [9] https://github.com/apache/maven/pull/1205 > > -- > ------------------------ > Guillaume Nodet >