Hi Michael, First, thanks for the patch; from my perspective, it hasn't been picked up only because I forgot about it.
For simplicity's sake, I would like to avoid the RepositoryArray adapter. I think repositories.remote could simply store Strings (assumed to be URIs), URI objects and hashes as-is; basically whatever the user puts in would be kept and returned without any change. That way, we keep everything backward compatible. However, the consumers of repositories.remote (incl. buildr itself) would now have to support Strings / URIs / hashes. Otherwise, I'm in favor of the change. I think it's a good idea to support hashes with auth options in repositories.remote. alex On Fri, Sep 16, 2011 at 4:32 PM, Michael Guymon <michael.guy...@gmail.com>wrote: > So ticket > https://issues.apache.org/**jira/browse/BUILDR-577<https://issues.apache.org/jira/browse/BUILDR-577>has > sat around for a few month and I doubt the patch is still valid. > > Allowing for explicit auth on a repo is a feature I am depending on in my > projects and have been monkey patching Buildr to support the { :url, > :username, :password } notation. I see the docs advocate the adding the > credentials to the url > (|http://user:password@**repository.example.com<http://user:passw...@repository.example.com>),|but > that is not flexible enough for my needs. I have been using Maven's Aether > framework for handling dependency resolution which requires explicit access > to the credentials when accessing repos with auth. > > Is this url concept still considered viable? I do not mind updating the > patch, otherwise I am open to creating a solution that is considered more > appropriate. > > thanks, > Michael > > > On 03/17/2011 10:54 PM, Alex Boisvert wrote: > > On Thu, Mar 17, 2011 at 2:38 PM, Michael Guymon > <michael.guy...@gmail.com<mailto: >> michael.guymon@gmail.**com <michael.guy...@gmail.com>>> wrote: >> >> >> I created a patch so that >> >> >> repositories.remote << { :url => 'https://a.secure.repo/maven2'**, >> :username => 'blah', :password => 'blah' } >> >> will work for http basic auth. When an artifact is downloaded, the >> auth information is passed to the HTTP transport. >> >> >> https://issues.apache.org/**jira/browse/BUILDR-577<https://issues.apache.org/jira/browse/BUILDR-577> >> >> >> Excellent! Thank you! >> >> There might be an issue with the patch, since it changes the >> format of repositories.remote. Instead of just being a String, it >> is stored as a hash {:url => URI} or with optional auth {:url => >> URI, :username => String, :password => String}. How horrible is >> this for backwards compatibility? >> >> >> Personally, I'm not too worried about it since it's an "opt-in" feature -- >> existing builds are not affected unless they use the feature. Plugins may >> need to be adapted to support the hash but that's usually a trivial change >> and I don't know of any plugin that uses repositories.remote to access URLs >> and such. >> >> alex >> >> >