Le dimanche 11 juin 2023, 23:31:36 CEST Hunter C Payne a écrit : > Strange question but maybe it will inspire someone else. Why does the POM > the user uses to control the build the exact same format as the POMs > created to express the results of the build? Is that necessary? it has been done in early Maven 2 and Maven Central creation, near 20 years ago: why do more complex? And how, when at that time all the concepts had to be invented and implemented to simply work first.
> It seems > to me the discussion is about the drawbacks of that approach. Perhaps its > needed for reproducible builds or something but it seems to me those two > use cases are different and the difficulty comes from trying to make one > stable format serve both use cases. Hunter that's why the concepts of build/consumer POM were introduced [1] 5 or 6 years ago and the plan about Maven 4 and 5 [2] with summaries of the history [3] done while working on it Regards, Hervé [1] https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM [2] https://cwiki.apache.org/confluence/display/MAVEN/Maven+Core+Roadmap [3] https://www.javaadvent.com/2021/12/from-maven-3-to-maven-5.html > > On Sunday, June 11, 2023 at 02:12:49 PM PDT, Romain Manni-Bucau > <rmannibu...@gmail.com> wrote: > Le dim. 11 juin 2023 à 22:28, Guillaume Nodet <gno...@apache.org> a écrit : > > Those are actually two different questions, but I'd like to raise those > > together, since they do affect the same feature. > > > > 1/ We currently don't have an XML schema for the build POM. One > > possibility would be to relax a bit the constraints on the main POM schema > > ( > > http://maven.apache.org/xsd/maven-4.0.0.xsd) so that some elements are not > > mandatory in the xml. By not modifying the validation rules, those > > elements will have to be present in the object model, so that should be > > safe. Another option would be to have a separate schema, but given the > > small set of changes on the build pom on the current constraints, i > > think the first solution would be better. As a reminder, the build pom > > supports: inferring version for artifacts that are part of the reactor > > (that's usually done using managedVersion), inferring the relativePath > > element, ci friendly interpolation for the version. > > +1 to relax > > > 2/ the consumer POM could be streamlined much more using the same > > techniques than used in the flatten-maven-plugin. Currently, we're only > > removing the <modules> element, but we could remove the full build > > section, > > flatten dependencies, etc... Packaged artifacts (i.e. with a non pom > > packaging), can only be used as dependencies, so I think the whole > > flattening process could make sense. Is there any drawback in doing so ? > > Any particular reason the consumer POM support is limited to removing > > modules and does not go further ? I can see some discussion in > > https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM > > but > > those do not seem to be settled. > > Doesnt flattening break transitive dep resolution since depth changes? > > Also drops some build meta which cant be resoled anymore portably like > compiler setup, which graalvm version was used and lastly would need to > drop or not props not used elsewhere. > Think staying as close as possible of the source is overall good to consume > as intended (build control) until the transformer is fully configurable > (never hopefully since it sounds overcomplicated). > > > Le ven. 9 juin 2023 à 11:22, Guillaume Nodet <gno...@apache.org> a écrit : > > > Le ven. 9 juin 2023 à 08:59, Hervé Boutemy <herve.bout...@free.fr> a > > > > > > écrit : > > >> adding a new POM element in build POM was supposed to be something for > > >> Maven 5 > > >> and to trigger a POM 5 version, to make clear that we are leaving the > > >> Maven 3 > > >> space (that uses POM version 4, hence the need for version > > >> clarification > > >> between Maven and it POM model version) > > >> > > >> if we enter that space before having released Maven 4, we're adding > > >> more > > >> complexity: do you really want to work on Maven 5 now? > > >> > > >> > > >> another aspect: > > >> do we want to have this new improvement only for Maven 4/5 or also have > > >> it for > > >> Maven 3.9? > > >> in Maven 3.9, such little enhancement were implemented as XML > > >> attributes > > > > > > Fwiw, if I reduce the diff between the XSD generated with 3.0 and with > > > 3.9.x, I end up with the following diff > > > https://gist.github.com/gnodet/f8dfd3206ebf55d6e4610a25e683120b > > > So, you're right, no new elements have been introduced. A few attributes > > > added, one element removed. > > > > > > However I really don't understand how adding an attribute vs an element > > > makes the POM more compatible. Our own generated parser will reject any > > > unknown new attribute the same way as an unknown element (that's for any > > > maven 3.x version). Here's what happen if I use a maven 3.2.5 to read a > > > > POM > > > > > with an element that has been introduced later: > > > https://gist.github.com/gnodet/35a3ad4d449e586dc282c08eacc82ed0 > > > So I'm not really buying the argument about attribute / element at this > > > point. If that could be clarified, it would be nice ! > > > > > > So I think the question comes down to: do we prefer > > > modifying/overwriting > > > the schema as we did in the past or do we prefer cleanly versioning it. > > > > In > > > > > both cases, I think we need to keep it compatible, i.e. only add > > > elements/attributes. The first option is much easier to implement: just > > > > do > > > > > nothing as we did in the past, but this has the drawback of not giving > > > people/tools much warning or information about possible changes. We > > > > simply > > > > > overwrite the schema from the web site with the latest one at each > > > > release, > > > > > hoping that tools will not see the change and that they don't really > > > > cache > > > > > the schema (in case you really need the latest). The other option is to > > > more properly version the schema. This would need additional code if we > > > want to correctly detect which version is the lower version needed to > > > correctly write a given POM. But even for doc changes, I think it may > > > be > > > preferable to micro version the schemas. > > > > > > The scm.child.xxx attributes that were added are not meaningful for the > > > consumer afaik: they are used for build time and for doc, when you use > > > an > > > artifact as a dependency (i.e. on the consumer side), those attributes > > > won't be used. So from a consumer POV, they don't carry any semantics > > > > and > > > > > can safely be silently discarded. This is also the case for this new > > > priority attribute, as it only affects the current project or child > > > projects. In that sense this new feature could just be silently added > > > to > > > the schema as previous things, so I'm fine with not versioning the > > > schema > > > now if that's the consensus. > > > > > > The problem (and that's really something we need to fix), is that we > > > > don't > > > > > any real difference between the build POM and the consumer POM schemas. > > > > We > > > > > also don't make a real difference between consuming as a bom / > > > > dependency / > > > > > plugin, and consuming as a parent. Both cases are really different, as > > > > the > > > > > first one could strip out most of the <build> section. One possibility > > > would be to more formerly identify those 3 use cases (build on file > > > > system, > > > > > consuming as a dependency and consuming as a child). Note that we're > > > currently lacking a build schema, so that when using the build/consumer > > > POM, your build schema cannot be validated, as it's missing some > > > > elements. > > > > > One possibility would be to simply make some elements non mandatory in > > > > the > > > > > schema. The model validation would check those anyway. For the > > > consumer > > > POM for non "pom" packaging, would it make sense to streamline the > > > > uploaded > > > > > POM even more: i.e. remove all build stuff from it (pluginRepositories, > > > pluginManagent, plugins, reporting, etc...) or is there any use case for > > > keeping those ? We could attach the build pom (i.e. we're currently > > > switching the POM when installing/deploying it, but it's attached with a > > > "consumer" classifier during the build). > > > > > > Guillaume > > > > > >> and of course, independently from this XML mapping and version details, > > >> there > > >> is the question to be seriously discussed about the feature itself: is > > >> this > > >> opportunity of introducing the "priority" field something we want (that > > >> reuses > > >> an implementation that is de-facto already existing internally for a > > > > long > > > > >> time, it just exposes it) > > >> > > >> Regards, > > >> > > >> Hervé > > >> > > >> Le jeudi 8 juin 2023, 22:56:27 CEST Guillaume Nodet a écrit : > > >> > While working on an issue [1], I've raised a PR [2] which is adding > > >> > an > > >> > > >> xml > > >> > > >> > element to the POM. So I raised the model version to 4.2.0. My > > >> > understanding is that the build/consumer POM feature [3] was created > > > > so > > > > >> > that we could keep compatibility. This is clearly indicated in the > > > > wiki > > > > >> > page: "Maven is stuck on POM v4 for a long time now, because > > >> > changing > > >> > > >> the > > >> > > >> > POM version and publishing artifacts on Maven Central with this new > > >> > > >> model > > >> > > >> > would break consumers using either older Maven versions or other > > >> > build > > >> > tools (that use POM v4 as a compatibility format)." > > >> > > > >> > However, I think this axiom is false. What happens, is that all > > >> > maven > > >> > versions are perfectly capable of consuming any model when used as a > > >> > > >> BOM / > > >> > > >> > dependency / plugin, as the parser simply ignores any unknown > > > > attribute > > > > >> or > > >> > > >> > element. I can install a jar with the 4.2.0 model and consume it > > >> > with > > >> > > >> any > > >> > > >> > 3.x version without any problem. The only issue is when using that > > >> > > >> project > > >> > > >> > as a parent, in which case, the validation is strict and fails with > > > > the > > > > >> > 4.2.0 model. > > >> > > > >> > So, saying that "new model would break consumers using [...] older > > > > Maven > > > > >> > versions" is just wrong, as they work perfectly when consuming the > > >> > POM > > >> > > >> as > > >> > > >> > dependencies. I can create a small git repo if you want to > > > > experiment, > > > > >> but > > >> > > >> > that has been first checked by @cstamas, then double checked by > > > > myself. > > > > >> > Now, the discussion is whether we want to allow modifications to the > > > > POM > > > > >> > model and support new versions of it. I think this would be quite > > > > safe, > > > > >> > provided that there's no incompatible changes, i.e. it's only adding > > > > new > > > > >> > elements/attributes. > > >> > I don't think this goes against the build/consumer feature, as I > > >> > think > > >> > > >> the > > >> > > >> > main benefit of this feature is to allow default values using sane > > >> > conventions (mainly the project layout on the file system, which is > > > > not > > > > >> > available anymore in the remote repository, so this data has to be > > >> > > >> present > > >> > > >> > for consumers). > > >> > > > >> > So, the question: should we go ahead and allow introducing newer POM > > >> > > >> models > > >> > > >> > to bring in a few features that have been delayed for a long time > > >> > > >> because > > >> > > >> > the assumption was that the model could never change ? One > > > > possibility > > > > >> to > > >> > > >> > minimize the disruption would be to have a smart POM writer : i.e. it > > >> > > >> could > > >> > > >> > transform the POM to a 4.0.0 model if no new features are actually > > >> > > >> used, so > > >> > > >> > that only projects actually using the newly introduced features would > > >> > actually use the 4.x pom version. > > >> > > > >> > Guillaume > > >> > > > >> > [1] https://issues.apache.org/jira/browse/MNG-7804 > > >> > [2] https://github.com/apache/maven/pull/1147 > > >> > [3] > > >> > > >> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM > > >> > > >> > > >> > > >> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > >> For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > -- > > > ------------------------ > > > Guillaume Nodet > > > > -- > > ------------------------ > > Guillaume Nodet --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
