On 28/08/2011, at 12:15 AM, [email protected] wrote: > > Spencer Allain <[email protected]> wrote on 08/27/2011 08:22:13 AM: > >> From: Spencer Allain <[email protected]> >> To: [email protected] >> Date: 08/27/2011 08:29 AM >> Subject: Re: [gradle-user] Re: Use mavenCentral() as a default >> repository unless specified otherwise? >> >> --- On Sat, 8/27/11, evgenyg <[email protected]> wrote: >> Luke Daley-2 wrote: >>> >>> Even with that plugin I'm not sure it's a good idea. >>> >> >> I see. Can you list the reasons? I'm not a big fan of Maven Central > either >> and run my own Artifactory repo. >> The reason I thought it could make sense is that standard open-source >> projects without requirements of additional repositories work only with >> Central. >> A default build that attempts to externally connect to the outside >> world would quickly get gradle banned from many commercial organizations. >> >> Also, it would have an unexpected performance impact for anyone >> attempting to use local repositories and not know how to turn off >> the default mavenCentral behavior (which would be the novice users >> who likely would be most turned off by slow performance). >> >> -Spencer > > It seems to me that repository information should by default live in the > user's home directory. I don't think it should be up to a gradle script to > define repositories. At my company, we've written custom plugins that look > to a gradle.properties in the user's home directory to define repository > urls. It would be nice if there could be a more default mechanism for > this. > > My choice of repository is not usually specific to a script, but tends to > be more universal depending on my environment. Especially in the corporate > world behind an internet proxy, and a maven proxy like Artifactory or > Nexus.
There are a few problems with (by default) defining repositories outside the build: * Your build is not self-contained. In order to use it, you have to deploy some file to each machine where it is to be built. If you need to roll out your build to 5000 developer machines, this approach is a non-starter. It adds more work to provisioning build machines. Then you need to worry about pushing changes to the repository definitions to everywhere it needs to go. * Your build is not change controlled. You'll get different results based on where you build. And the build won't be reproducible, without some extra effort to snapshot the repository definitions that were used. * You can't have different builds which use different infrastructure. It sounds like what you need is some better way to probe the environment. Generally, the choice of which repositories to use is not a function of who is running the build, but a function of where the build is running. With the daemon, we can probe various repositories, and use whichever one happens to be available. This way, the build can say, 'use this artifactory instance if reachable, otherwise use this public instance, otherwise switch to offline mode and use whatever you have cached'. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
