Re: Auth for Buildr repositories.remote

[Michael Guymon <mi...@gmail.com>]

So ticket 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),|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.guymon@gmail.com <ma...@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
>
>
> 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
>

Re: Auth for Buildr repositories.remote

[Alex Boisvert <al...@gmail.com>]

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 <mi...@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<ht...@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.guymon@gmail.com<mailto:
>> michael.guymon@gmail.**com <mi...@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
>>
>>
>