2009/10/28 John Casey <jdca...@commonjava.org> > I tend to agree, they should not really be used. It seems like these > third-party repositories have a strong potential for causing network errors > (in cases where the repo is down or on a private network), and they > definitely push the user in the direction of trusting anything that comes > from anywhere on the internet without thinking twice...not a great idea, and > an understandably unpopular one with companies. > > I think the role of the <repository> declaration in the POM should be > shifted in Maven 3. I think this along the same lines that Brett was > talking, but I'd really like to see them take on an advisory role rather > than actively participate in resolution. In other words, if an artifact > cannot be found, then display the list of third-party repositories which > MIGHT contain the artifact, along with the POM that lists that repository. > > This would help users request new repositories be added to the repo manager > in cases where there is one, and otherwise get permission to add the repo to > their settings.xml. In short, Maven would tell the user the most likely > reason the build cannot proceed, but not assume it's okey to pursue the > artifact to the ends of the earth. > > +1
> -john > > > Paul Gier wrote: > >> I really think it should not be allowed, since it makes the builds less >> predictable/reproduceable/secure. Most people I've talked to think it's a >> bug when they first see it happening because they are trying to figure out >> why Maven is downloading files from a random location on the Internet. >> >> The people who have a corporate policy to only download from central are >> already breaking their policy whether they list the alternate repo in >> settings.xml or it is added from a dependency. >> >> With that said, I'm ok with having it configurable as Jesse suggests as >> long as the default behaviour is to not add the repositories to the build. >> >> Jesse McConnell wrote: >> >>> judging from the response I have gotten from people both wanting and >>> not wanting repositories declared for various integrations with jetty, >>> the problem folks seem to be ones where their corporate policy dictate >>> they can not use any repo other then central but they do not have a >>> repo manager setup. >>> >>> since we can't rightly force people to install and maintain repository >>> managers, at first blush I would probably error on the side of a >>> option in the settings.xml a la offline >>> >>> <transitiveRepositories>true/false</transtiveRepositories> >>> >>> jesse >>> >>> -- >>> jesse mcconnell >>> jesse.mcconn...@gmail.com >>> >>> >>> >>> On Wed, Oct 28, 2009 at 07:03, Brett Porter <br...@apache.org> wrote: >>> >>>> I would advocate not allowing them, but using them to provide useful >>>> information in the case of a resolution exception that can easily guide >>>> the >>>> user on what to do. >>>> >>>> If folks strongly want to continue to allow it, I would go with a >>>> prominent >>>> warning (which is the case for several other things now). >>>> >>>> As to what the user is guided to do - I assume that is to declare them >>>> as >>>> repositories in the current project, or to refer to their repository >>>> manager's documentation to add it there (with this being recommended). >>>> In >>>> the long run I'd hope Maven can better handle multiple repositories OOTB >>>> (in >>>> a way that still complements the use of a repository manager) - actually >>>> I >>>> remember briefly talking to Brian about that at last year's ApacheCon >>>> Maven >>>> BOF :) Time flies... >>>> >>>> - Brett >>>> >>>> On 28/10/2009, at 10:52 PM, Benjamin Bentmann wrote: >>>> >>>> Hi, >>>>> >>>>> following a comment by Wendy on JIRA, I wanted to re-check what our >>>>> plans >>>>> are for repositories in dependency POMs. In more detail, how is >>>>> dependency >>>>> resolution in Maven 3.x expected to work here: >>>>> >>>>> project ---depends-on---> A ---depends-on---> B >>>>> >>>>> where the POM of A declares the repository R hosting B. >>>>> >>>>> Now, when it comes to resolve B's POM/JAR (and its transitive >>>>> dependencies) in the context of building the project, should Maven 3 >>>>> also >>>>> consider R (like currently done in Maven 2) or only those repositories >>>>> that >>>>> are available for the root of the dependency graph, i.e. the >>>>> repositories >>>>> declared in the POM of the project and the settings? >>>>> >>>>> Besides the question of the degree of backward-compat we want to keep, >>>>> the >>>>> issue with ignoring the repositories declared in dependency POMs I see >>>>> is >>>>> the effect on open source projects and their consumers. If one project >>>>> consumes the artifacts of another, do we want the first project to >>>>> redeclare >>>>> all repositories required to resolve the transitive dependencies of the >>>>> second project? Some arguments for the other side can be found in [1]. >>>>> >>>>> So, where do we want to go with this? >>>>> >>>>> >>>>> Benjamin >>>>> >>>>> >>>>> [0] >>>>> >>>>> http://jira.codehaus.org/browse/MNG-4413?focusedCommentId=196344&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_196344 >>>>> [1] http://jira.codehaus.org/browse/MNG-3056 >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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 > >
