On 03/12/2011, at 2:22 PM, Hani Suleiman wrote:
> This would be great, especially if it'd work with uploading artifacts.
This is the plan. There's 3 things we'd like to do here:
* Use the same DSL for declaring repositories for downloading and for declaring
repositories for uploading. This is already the case for Ivy repos, but for
Maven repos the DSL is still different. When we make this change, we will have
a consistent way of declaring the credentials to use for a repository.
* Allow you to provide some logic for determining the credentials, rather than
providing a username and password. Making the credentials { } closure lazy is
one option here. However we do this, the logic will be invoked on demand. And
there'll be some way to reuse the result (eg for both downloading and uploading
to the same repository in the same build) and/or the logic (eg for using the
same logic for multiple repositories or multiple builds).
* Verify the credentials as early as possible in the build. So, if the build is
going to download stuff, prompt for and verify the credentials at the start of
the build (eg actually try to authenticate with the repository). Same for
uploading.
> I had to struggle a fair bit and do a lot of unpleasant hackery to get
> uploading archives working with prompting for credentials (and this was
> against m3, haven't dared try it with m6!)
>
> On Dec 2, 2011, at 4:15 PM, Carr, Brian M wrote:
>
>> This leads to a question I've been wondering about: Is it possible or
>> reasonable to make the credentials closure lazy evaluated. Right now, it
>> executes the closure whether or not it's necessary to download artifacts.
>>
>> I can imagine a scenario where you had a maven definition:
>>
>> maven {
>> url 'foo.bar.com'
>> credentials {
>> username doSomeFancyLookup()
>> password doAnotherFancyLookup()
>> }
>> }
>>
>> where the username and password properties could follow a resolution order.
>> If the properties were set in gradle.properties or init.gradle, use those.
>> If a console is available, use readPassword. If the jvm isn't headless, use
>> Swing. or any other credential looking you might think of.
>>
>> This approach only makes sense if the properties are lazy-loaded though,
>> otherwise they get executed on every build.
>>
>>
>> --b
>>
>>
>> On Dec 2, 2011, at 2:43 PM, Daz DeBoer wrote:
>>
>>> The first form (maven{}) is more idiomatic. The primary difference between
>>> maven{} and mavenRepo() is that the latter returns the underlying ivy
>>> DependencyResolver instance, which can be manipulated directly. Once we are
>>> happy that maven{} supports all of the reasonable use cases for dependency
>>> resolution, mavenRepo will likely be deprecated.
>>>
>>> The reason for this change is that we are moving away from exposing ivy as
>>> part of our API. The motivation is that we want to be able to provide a
>>> richer, more domain-specific api for dependency resolution, and not be tied
>>> to the ivy API or implementation.
>>>
>>> One benefit to the maven{} syntax is that it provides the ability to
>>> lazy-evaluate the url (and other) parameters, whereas the url parameter of
>>> mavenRepo must be know at the time of declaring the repository.
>>>
>>> cheers
>>> Daz
>>>
>>> On 2 December 2011 11:24, Russel Winder <[email protected]> wrote:
>>> Quick question as to whether one form is more idiomatic than the other:
>>>
>>> repositories {
>>> mavenCentral ( )
>>> maven { url 'http://repository.codehaus.org/' }
>>> }
>>>
>>> or
>>>
>>> repositories {
>>> mavenCentral ( )
>>> mavenRepo url : 'http://repository.codehaus.org/'
>>> }
>>>
>>> Thanks.
>>>
>>> --
>>> Russel.
>>> =============================================================================
>>> Dr Russel Winder t: +44 20 7585 2200 voip:
>>> sip:[email protected]
>>> 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected]
>>> London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
>>>
>>>
>>>
>>> --
>>> Darrell (Daz) DeBoer
>>> Principal Engineer, Gradleware
>>> http://www.gradleware.com
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
