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?


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


Reply via email to