2009/10/28 Stephen Connolly <stephen.alan.conno...@gmail.com> > 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 >
Note that this would print out big ugly warning messages and prompt for each repository... but at least people don't have to figure out how to edit their settings.xml ;-) > 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 >> > >> > >> > >
