On 16/04/2013, at 10:30 PM, Steve Ebersole <steven.ebers...@gmail.com> wrote:
> Sigh. Daz mentioned that credentials get copied from the upload repo > definitions. > > Look, I just want to know what I need to do in order to apply a set of > credentials to a maven repository to be used for upload. Is that possible? > If so how? Been asking that for almost 2 weeks now ;) > > P.S. I am also not seeing a way to define a split between "production" and > "snapshot" repo urls for publishing the way we used to be able to do with > uploadArchives.repositories.mavenDeployer. Is that also no longer supported? > If not, I guess that is something I need to handle "manually" in the script > to conditionally set the url? It's not in the new stuff yet, so you'll need to deal with this manually for now. > > > On Tue 16 Apr 2013 07:25:04 AM CDT, Luke Daley wrote: >> >> On 16/04/2013, at 1:19 PM, Steve Ebersole <st...@hibernate.org> wrote: >> >>> So am I understanding that the only way to get this (applying "publish >>> repo" credentials) is to add credentials to a MavenArtifactRepository? >>> >>> What I am not understanding is what to do in the (seemingly normal) use >>> case where the publish repo is not an artifact (download) repo. >> >> The set of consumption repositories is a different set to the publication >> repositories. >> >>> >>> >>> On Sat 06 Apr 2013 08:47:15 PM CDT, Daz DeBoer wrote: >>>> If you didn't find it, the DSL docs for the Publishing Extension and >>>> related model elements might be useful: >>>> http://www.gradle.org/docs/nightly/dsl/org.gradle.api.publish.PublishingExtension.html. >>>> For some classes (eg PublicationContainer) the javadoc is probably >>>> more useful than the DSL reference (click the "API Documentation" link >>>> from the DSL page). >>>> >>>> Other than that, the best way to understand what's going on is to >>>> consult the sources. >>>> >>>> One thing that is not well documented is the new, experimental support >>>> for deferred configuration that is leveraged by the >>>> PublishingExtension. This extension is a {@link >>>> org.gradle.api.plugins.DeferredConfigurable} model element, meaning >>>> that extension will not be configured until it is first accessed in >>>> the build. So any configuration blocks are not executed until either: >>>> >>>> 1. The project is about to execute >>>> or >>>> 2. The publishing extension is referenced as an instance, as opposed >>>> to a configuration closure. ie: >>>> publishing.publications { ... } >>>> publishing.repositories.maven { ... } >>>> You can read the rationale behind deferred configuration in the design >>>> doc: >>>> https://github.com/gradle/gradle/blob/master/design-docs/lazy-configuration.md. >>>> We're interested in feedback and ideas of how we can make this clearer. >>>> >>>> If you were not aware of this, it's quite possible that you were >>>> causing the publishing extension to be configured early which could >>>> lead to hard-to-understand behaviour. >>>> >>>> I'm happy to help get things working, do you have some code to share? >>>> >>>> cheers >>>> Daz >>>> >>>> >>>> >>>> >>>> >>>> On 5 April 2013 15:47, Steve Ebersole <st...@hibernate.org >>>> <mailto:st...@hibernate.org>> wrote: >>>> >>>> I realize that this is an incubating feature, but given the >>>> current documentation I am really not able to get this to work. >>>> It works if I have something simple (no pom customization, no >>>> snapshot/releases repository distinction, etc). Is there some >>>> better documentation I shuld look at rather than >>>> http://www.gradle.org/docs/__current/userguide/publishing___maven.html >>>> <http://www.gradle.org/docs/current/userguide/publishing_maven.html> >>>> and the dsl docs for MavenPom/MavenPublication? >>>> >>>> >>>> On Fri 05 Apr 2013 02:50:42 PM CDT, Steve Ebersole wrote: >>>> >>>> Hey Daz, >>>> >>>> The "upload auth" plugin[1] reads credentials from maven >>>> settings.xml >>>> etc and applies them to any same-named repositories referenced >>>> in a >>>> Gradle build through an Upload task. So, as I understand it, that >>>> would not apply here. >>>> >>>> Applying the credentials to the resolution repos would be a >>>> good thing >>>> too. >>>> >>>> [1] https://github.com/sebersole/__gradle-upload-auth-plugin >>>> <https://github.com/sebersole/gradle-upload-auth-plugin> >>>> >>>> >>>> On Fri 05 Apr 2013 02:21:07 PM CDT, Daz DeBoer wrote: >>>> >>>> On 5 April 2013 07:16, Steve Ebersole <st...@hibernate.org >>>> <mailto:st...@hibernate.org> >>>> <mailto:st...@hibernate.org <mailto:st...@hibernate.org>>> >>>> wrote: >>>> >>>> I am just upgrading Hibernate to Gradle 1.5 and am >>>> reading about >>>> the new publications stuff. I really like the new DSL >>>> much, much >>>> better. >>>> >>>> I did have one question though that was not addressed >>>> in the docs. >>>> For the old style of "uploading" I had developed a >>>> plugin that >>>> provided authorization based on users local Maven >>>> install. From >>>> my recollection the intent in the new maven >>>> publication code was >>>> to provide this behavior out-of-the-box. So I am >>>> curious if that >>>> code ever made it into the >>>> MavenArtifactRepository/____MavenPublication code. Or >>>> do I need to >>>> update my gradle-upload-auth-plugin to handle this new >>>> API? >>>> >>>> >>>> The new Publication support copies the credentials from the >>>> MavenArtifactRepository (see the poorly named >>>> >>>> org.gradle.api.publish.maven.__internal.publisher.__MavenDeployerConfigurer). >>>> >>>> So any plugin code that you use to add credentials to maven >>>> repositories used for resolution should also work for >>>> publication. >>>> -- >>>> Darrell (Daz) DeBoer >>>> Principal Engineer, Gradleware >>>> http://www.gradleware.com <http://www.gradleware.com/> >>>> Join us at the Gradle Summit 2013, June 13th and 14th in >>>> Santa Clara, >>>> CA: http://www.gradlesummit.com <http://www.gradlesummit.com/> >>>> >>>> >>>> >>>> >>>> -- >>>> Darrell (Daz) DeBoer >>>> Principal Engineer, Gradleware >>>> http://www.gradleware.com <http://www.gradleware.com/> >>>> Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, >>>> CA: http://www.gradlesummit.com <http://www.gradlesummit.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 Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com
