[MNG-7059][MNG-4645] Move Central repo definition out of Maven's core so it can be more easily changed

[gnodet]

JIRA issue: https://issues.apache.org/jira/browse/MNG-4645
IT PR: apache/maven-integration-testing#266
Supersedes: #419

[rmannibucau]

Do we intend to break builds overriding settings? Guess injection logic should be kept until we force an implicit settings.xml or do not define any implicit packaging/lifecycle, no?

[gnodet]

Do we intend to break builds overriding settings? Guess injection logic should be kept until we force an implicit settings.xml or do not define any implicit packaging/lifecycle, no?

That's a really good question. I've added back the injection of maven central in case the settings read have no repositories defined. The most usual use case will be if the global settings have been overridden by the command line.

[gnodet]

Kinda weird that the only IT failing is because it's now using the newly accepted syntax, but we're testing a failure: https://github.com/apache/maven-integration-testing/blob/941353757073754cedd91f49c3d1d9c216adda0d/core-it-suite/src/test/resources/mng-3748/settings.xml ...

[cstamas]

Does this means maven4 settings.xml will not be parsable by Maven3? So projects will have to "take a stance", and be "maven4 only" or 'maven3 only"?

[gnodet]

Does this means maven4 settings.xml will not be parsable by Maven3? So projects will have to "take a stance", and be "maven4 only" or 'maven3 only"?

That's the settings.xml which will come with the maven 4 distribution and located in [MVN_HOME]/conf/settings.xml, so I don't think this is an issue. If people want to modify their own user settings and leverage new features, then yes, but as a workaround, it's always possible to use a profile activated by default instead.