I agree we can have tooling for that. We can imagine we add in user's settings a dedicated profile for the project with all repositories (but for that we have to reactivate the repositories chain to discover them ;-) )
On Wed, Oct 28, 2009 at 4:56 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > 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 > >> > > >> > > >> > > > > >
