Le lun. 12 juin 2023 à 01:36, Guillaume Nodet <[email protected]> a écrit :
> Le dim. 11 juin 2023 à 23:12, Romain Manni-Bucau <[email protected]> a > écrit : > > > > > > > Le dim. 11 juin 2023 à 22:28, Guillaume Nodet <[email protected]> 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). > > > > All those properties, plugin config, etc... are completely irrelevant for > jars or any other packaged artifact. The only way those can actually have > an impact is when you use the pom as a parent. That's because when you > inherit from a project, it has to have the "pom" packaging. Dependency > management is used when importing BOMs, but all other usages are afaik > limited to declaring dependencies or plugins, and in those cases, the only > interesting bits are dependencies, dependencyManagement, parents and > properties (+ repositories). The flatten-m-p does merge those 4 pieces > into a single list of dependencies (which has the benefit of simplifying > the consumption of the artifact). We may not want to do that, but still > the build section is completely irrelevant. > Do you assume people only use pom as a dependencies source? it is used for way more than that IMHO. While I agree how plugins are executed is not important, how they are configured is used and adds value to consumers. A simple example (but trust me I saw some more complex in companie$) is to check compiler configs to ensure the assumed based runtime will work, indeed it is part of a static analyzis (and rarely the build) but the used source is the deployed pom and I strongly think it is an important metadata. Indeed you can say all that must be replaced by some metadata files but, as of today, the pom gives that quite easily and pseudo portably (you just compensate artifacts not using maven with explicit meta but it is a few compared to dropping it globally). > > To recap, we have 3 different usages of the POM: > * the build pom on the file system read by maven when running > * the consumer pom on a repository which is used when consuming a > dependency/plugin jar or any other kind of packaging > * the build pom with a pom packaging which can be uploaded to central and > used as a parent by another project > Agree > > I do somewhat understand the will to keep the pom schema for artifacts > uploaded in central. When consuming those jars (as dependencies or > plugins), there's definitely very little need to actually make any change > to the POM schema that they are using (even though I'm not really buying > the fact that it has to be set in "amber"). Maven already supports any new > element/attribute and other tools could adapt as well. > However, there are clear needs to improve the build side POM. The > build/pom consumer has done some improvement here, but it's not finished, > and the pain point has not been addressed in any doc/wiki page I've read so > far: if we ever introduce a new element in the build POM, but we want to > consume that POM as a parent: this is the third usage above, and it's > conflicting with two set of goals: > * introduce new stuff in the build pom > * keep 4.0.0 model in "amber" > I think the only way is to create a new schema called POM5 if you want and > to use it for build POM *and* for pom packaged POM uploaded to central, > while packaged artifacts would be stuck with POM4. The POM5 could then be > free to evolve as desired. > This is where I'm not 100% sure, we should keep a build pom normalized format (as close as v4 if possible, ex: no inline gav if we allow inline gav in v5). So means we can need 3 poms: 1. raw user build pom 2. consumer pom (mainly deps) 3. full deployed pom (normalized format of 1 but complete with no flattening). Note here: we must not use the pom formatter which breaks null/empty values as in release plugin :(. Side note: no issue for me if version evolves or xsd evolves while shape looks close and backward compat when possible for partial readers. > > So to sum-up, I can see two solutions: > * allow the 4.0.0 model to evolve with 4.2.0 or any other. If we don't > touch the "consuming" side of things, old maven will still work and be able > to consumer jars uploaded (and we could still upload a 4.0.0 pom for jars > if we remove the build section and everything that's irrelevant to consume > those jars) > * introduce a new schema for the build pom (be it > http://maven.apache.org/POM/5.0.0 or http://maven.apache.org/BUILD/4.0.0, > or whatever...) and allow it's usage for build poms and consequently allow > uploading those to central for pom packaging, while packaged artifacts > could be converted to the current 4.0.0 model and stripped from the build > section) > > Both solutions are roughly the same, there's not much difference: in both > cases, we need to strip out the build information from the packaged > artifacts before uploading on central (the build pom could be attached for > reference though). Then, it's just about whether we keep the current > namespace and change the version, or create a new one. It's basically a > matter of taste... > On my side I will not fight much on the version and way we make it evolving but I'd like to keep the completeness of the information on central in the most backward compat version, can just be a release plugin evolution adding a 3rd pom as explained before but think it helps the ecosystem to not break everything while enabling us to evolve as we wish. Hope it makes sense > > > > > > > >> Le ven. 9 juin 2023 à 11:22, Guillaume Nodet <[email protected]> a > écrit > >> : > >> > >> > > >> > > >> > Le ven. 9 juin 2023 à 08:59, Hervé Boutemy <[email protected]> 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: [email protected] > >> >> For additional commands, e-mail: [email protected] > >> >> > >> >> > >> > > >> > -- > >> > ------------------------ > >> > Guillaume Nodet > >> > > >> > > >> > >> -- > >> ------------------------ > >> Guillaume Nodet > >> > > > > -- > ------------------------ > Guillaume Nodet >
