These arguments are good and makes lot of sense for people proxying
repositories.
But assuming someone works on multiple projects, then his
settings.xml is polluted with a lot of stuff coming from other
projects, and then the build that will happen on his machine may
differ a lot from the "normal/maintained" one. So that means that
all project have to ship its settings.xml containing the repository
to reference, and profiles related to enablement of these
repositories. We'll have to split pom.xml into pom.xml +
settings.xml. It makes things more complicated for maintainers and
consumers, but makes sense in case of an "enterprise" deployment of
Maven. Also please note that if you don't want the build to contain
any reference to a repository, this is also an argument against
target platforms since they directly refer to repository. I'll
investigate on how dependencyManagement works with Tycho.
In a nutshell: What you'd like is a pattern that decouples
dependency source (to be overriden when necessary) and dependency
management. It adds complexity and it is the contrary of what TP do.
--