I have several alternative design ideas. 0) If you religiously use a repository manager and mirrorOf "*", you can prevent this rogues from bothering you.
1) How about if the release / deploy process had an option to remove repositories from the POM? 2) Let's design and implement basic repository redirection in maven itself, so that people don't have to set up an entire repo-man to compensate for stupid <repository> elements in poms. 3) Let's fix the ?bug? in which a <repository> in a POM is used to look up artifacts other than the dependences of that very pom. 4) Let's fix the ?bug? in which a <pluginRepository> in a dependency effects lookups of plugins. <pluginRepository> elements should only have impact the starting POM or its parents. (I'm not 100% sure that this problem exists). All in all there's a tension. Repos move around and are managed, so putting them in POMs causes problems. Not putting them in POMs causes other problems. So I'm in favor of viewing repository elements in dependencies as hints rather than directions to add them unconditionally to the front of the search list. On Mon, Aug 1, 2011 at 3:58 PM, Paul Gier <pg...@redhat.com> wrote: > Using a project local settings allows you to use the repo during build, > but still have a clean pom in the repo when you release. We've > experienced a lot of problems related to repos in the poms. > > On 08/01/2011 02:16 PM, Julien HENRY wrote: >> What is the point of putting a settings.xml in your SCM next to your >> pom.xml? In this case just add the repos in the root pom. >> >> ++ >> >> Julien >> >> >> >> ----- Mail original ----- >>> De : Milos Kleint <mkle...@gmail.com> >>> À : Maven Developers List <dev@maven.apache.org> >>> Cc : >>> Envoyé le : Lundi 1 Août 2011 21h02 >>> Objet : Re: [DISCUSS] Project local setting.xml >>> >>> hasn't that been the purpose of profiles.xml files back in 2.x before >>> it was removed for 3.x? >>> >>> Milos >>> >>> On Mon, Aug 1, 2011 at 9:00 PM, Paul Gier <pg...@redhat.com> wrote: >>>> I'd like to discuss the possibility of Maven automatically looking for >>> a >>>> project specific settings.xml file [1]. The main use case for this is >>>> to eliminate, or at least reduce, the need to add repositories to the >>>> poms. A setting.xml file could simply be added into scm into the root >>>> directory of the project. Then it would be checked out when the project >>>> is checked out. >>>> >>>> With multi-module projects, Maven would need to search up the directory >>>> tree to find the settings.xml file, but this could be made relatively >>>> simple by checking the parent dirs until Maven finds: >>>> (1) a settings.xml, (2) a directory with no pom.xml, or (3) the root >>>> directory >>>> >>>> The only problem I can think of in this case would be when small related >>>> projects can be checked out separately (similar to Maven plugins, or >>>> codehaus mojo). The project might not be able to find the settings.xml >>>> if it is not checked out with the project. Although I think this is a >>>> relatively minor issue. >>>> >>>> [1]http://jira.codehaus.org/browse/MNG-4686 >>>> >>>> --------------------------------------------------------------------- >>>> 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 >>> >> >> --------------------------------------------------------------------- >> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
