> guys - please read up on how maven works and how its recommended
to use.
>
>
>
http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-p...
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.
As said, its not the Tycho repositories i'm talking about (if we just used .target
files we would remove this issue completely) - its the adding of
jboss.org maven repo (or
any other external maven repo) to a pom.xml which is being referenced by users.
Their builds not ours then becomes affected by our repository additions which is bad
behavior.
/max