On Wed October 28 2009 10:53:10 am John Casey wrote: > 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.
I'm OK with that EXCEPT for repositories defined in the current pom+parents. For transitive dependencies, yes, but not for building the current project. Dan > > 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. > > -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 > >> > >> 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#acti > >>>>on_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 > -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
