Can resolve from multiple Maven repository defined in the pluginRepositories block

[oehme]

Motivation

Some organizations might have multiple plugin repositories are a developer might want to try out a plugin deployed to mavenLocal() before pushing a change. Allowing multiple Maven repositories will solve these use cases.

Proposed Change

Instead of passing a single repository URL to the ScriptHandler of the current build script, we need to globally add the declared plugin repositories to the locations from where plugin jars are resolved. The current idea is to prepend them to the repositories of each initScript/buildScript block.

Each repository will be added to the list of plugin resolvers as a separate resolver. This will give the user better diagnostic messages and will later enable us to insert the Gradle Plugin Portal at any location between other repositories, see #22.

Code Review

• [] Does the change work?
  • [] Try out the feature, executing it like a end-user would.
  • [] Check corner cases and try to break it in various ways.
  • [] Are the error messages informative?
• [] Is the change sufficiently tested?
  • [] Are there appropriate levels of unit & integration tests?
  • [] Do the tests indicate what they are actually testing?
  • [] Are the tests in the right location?
  • [] Can new tests be consolidated with any existing tests?
• [] Does it change the public API?
  • [] Has @Incubating been used appropriately?
  • [] Does it preserve backward compatibility?
• [] Is it sufficiently documented?
  • [] Is the user guide documentation in the best location?
  • [] Is the user guide documentation clear and informative?
  • [] If there should be samples, are they helpful and tested appropriately?
  • [] Is there sufficient API/DSL documentation?
  • [] Is the API/DSL documentation clear and informative?
  • [] Do the release notes clearly convey the value of the feature?
  • [] Do the release notes explain the feature and link to more documentation?
• [] Is it implemented well?
  • [] Does it minimize surface area (particularly public)?
  • [] Does it follow our coding conventions? (note that we don't have coding conventions formalized but it's something to keep in mind)
  • [] Does it use appropriate data structures?
  • [] Does it minimize potential for invalid states?
  • [] Does it suitably reuse existing infrastructure?
  • [] Does it suitably consider concurrency?
  • [] Does it suitably consider failure modes?
  • [] Does it suitably consider performance?
  • [] Does it introduce new types or move existing ones? Are they located in the appropriate package? (e.g. internal classes in internal packages)