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.
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
