On 08/01/2011 03:09 PM, Benson Margulies wrote: > I have several alternative design ideas. > > 0) If you religiously use a repository manager and mirrorOf "*", you > can prevent this rogues from bothering you. >
This only works when all the projects you work on use the same mirror settings. For me, this doesn't work, and I would like to have different mirror settings for different projects. > 1) How about if the release / deploy process had an option to remove > repositories from the POM? > Yes, this would work well for me, but from what I understand, there are a lot of problems with modifying the POM right before deployment. It breaks gpg signing for example. > 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. > I basically agree with you. IMO repositories in dependency POMs should just be ignored by default. This definitely seems like a bug to me, and I've heard a lot of complaints from others when their build starts downloading stuff from some seemingly random location on the internet. http://jira.codehaus.org/browse/MNG-3056 > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
