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> 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>> 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
Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA:
http://www.gradlesummit.com
