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. 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 > >
