On Fri, 9 Jun 2023 at 16:23, Heiko Studt <heiko.st...@iteg.at> wrote: > > Hallo, > > Quote: > > the pom with a hardcoded version of the schema. > > But frankly let's consider this as a bug in the tool/ide doing so. > > Sorry to disagree: from a security standpoint, XSD is sufficient complex > enough that I do not want to download one from a random location on the > internet, especially if this means to remove hard constraints on what > will be parsed by the second stage (after validation) within my tool or > within mvn.
is this really a random location xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/maven-v4_0_0.xsd"; ? As long as the tool use this what is the problem to validate them against something such xsi:schemaLocation="http://maven.apache.org/POM/4.2.0 https://maven.apache.org/maven-v4_2_0.xsd"; > > I have had some experience with utilizing XSD for generating tools to > consume and some backwards compatibility issues. Whether the consumer > will work dependends *a lot* on the features of XSD you are using and > whether those changes are *truely* compatible with the (generated!) > parser for a specific language. > There are quite a few legacy parsers out... > > For example, in XSD the "sequence" has a misleading name, because you > cannot introduce any elements in-between or fail (only) the backwards > compatibility, while everything will work inside the new-version-using > ecosystem. > The problem arises only on sequence mempers *after* the one introduced > and shows itself by not transfering these "extra" old ones into the > object. It is quite surprising to find objects without said properties, > while the XML input had the corresponding elements set quite clearly and > loudly... > => Additionally, this cannot be unit-tested against efficiently, because > you need a full compatibility matrix and it depends on the consumer tool > which are plenty as well > > Another problematic one is the "enumeration" which might break your > parser if an unknown value (from the next version) was allowed by the > schema validation and cannot be fit into the target language code's enum > type. > > However, both these features are not used in a problematic fassion in > the current Maven POM XSD, so argueably this does not matter. > But, perhaps these are why the fixed approach is different on adding > attributes vs adding elements, as attributes are always non-sequential. > > I would suggest to put all the new XSD features onto a major version > update, as any update into e.g. maven 4 will be seen as a compatibility > risk anyways and therefore tested more extensively and manually after > adoption. > > To why the dependencies are leniently validated instead: probably there > are only a few features of the POM being used anyways. New elements or > attributes, like the priority, do not need to break the dependency tree > of the built artifact!?! > Otherwise one library using a newer maven version as its build tool will > break any consumer utilizing an older maven version. > > > Just my 2 cent > MfG (Kind regards) > > Heiko Studt > > Am 09.06.23 um 03:02 schrieb Olivier Lamy: > > sounds like a new feature (MNG-7804) > > The only problem I can imagine is with tools/ide consuming the build > > pom if they do not respect the xmlns and schemaLocation by validating > > the pom with a hardcoded version of the schema. > > But frankly let's consider this as a bug in the tool/ide doing so. > > > > > > On Fri, 9 Jun 2023 at 06:57, Guillaume Nodet <gno...@apache.org> wrote: > >> > >> 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 > >> -- > >> ------------------------ > >> Guillaume Nodet > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > MFG > -- > Heiko Studt > Senior Software Developer > ------------------------------------------------------------------------ > ITEG IT-Engineers GmbH | Salurner Straße 18, A-6020 Innsbruck > FN 365826f | Handelsgericht Innsbruck | Mobiltelefon: +43 677 63983071 > Mail: heiko.st...@iteg.at | Web http://www.iteg.at/team/hstudt > ------------------------------------------------------------------------ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
