2009/10/28 Arnaud HERITIER <aherit...@gmail.com> > I would like also that we don't use repositories defined in poms for all > reasons explained above. > It's right that changing this behavior will have an important impact > because > it could be difficult in certain cases to have an OOTB Build (svn co + mvn > install). Having to update user's settings isn't fun but at least they have > to understand what they are doing and they don't rely on some Maven magic. >
Also there is nothing stopping us from writting a plugin that imports the repositories into your settings.xml In which case for an out of the box build, you would do something like svn co mvn bootstrap:settings mvn install > For corporate environment they are already doing it to define the global > proxy and it is now easier with plugins like the one in nexus. > If we continue to define repositories in POM not to resolve artifacts but > just to document the build with a nice warning from maven with repo lists > when an artifact isn't found, I think we could have a good compromise. > > Arnaud > > On Wed, Oct 28, 2009 at 4:16 PM, John Casey <jdca...@commonjava.org> > wrote: > > > Most debian packagers that don't have their apps in the default APT > sources > > provide a standard page somewhere on their website for adding a new > source. > > This would be pretty easy for third-party repository providers to do, and > > would have the added benefit of making them really think about it and > > support that repository as public infrastructure...along with providing > > ticket/bug tracking for that repository's reachability along with the > build > > files or the source code for the app itself. > > > > Of course, there's not much reason I can think of that an OSS project > > wouldn't just configure synchronization with central if they're going to > go > > to all this trouble...but for non-OSS I can see them using the above. In > > that case, there's a chance they would want to authenticate/control > access > > to that repository anyway, in which case the user would need to modify > his > > settings.xml anyway... > > > > -john > > > > > > Jesse McConnell wrote: > > > >> The problem I see is that without being able to push up repositories > >> with third party artifacts that are not in central yet you still > >> depend on for integrations or things like that...you are out of luck > >> and need some mechanism of pushing that knowledge/information to the > >> user of the artifact...and a wiki page or a webpage detailing that is > >> not acceptable imo as it makes it difficult for the user as they need > >> to _find_ that page. > >> > >> Now I would be pro notification as well, along the lines that brett > >> was mentioning I think > >> > >> I can declare a repo in a third party integration, perhaps against a > >> corporate repo that has some open source component they are not > >> syncing to central....and that is _ignored_ in the build, ie never > >> consulted, but when that is detected and if the build is not able to > >> complete it should pump out that information to the user declaring > >> that other repositories have been detected and that perhaps missing > >> dependencies are located in there... > >> > >> jesse > >> > >> -- > >> jesse mcconnell > >> jesse.mcconn...@gmail.com > >> > >> > >> > >> On Wed, Oct 28, 2009 at 09:17, Paul Gier <pg...@redhat.com> 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 > >> > >> > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
