On 07/05/2013, at 11:26 PM, Steve Ebersole <[email protected]> wrote:
> I think that depends on the use cases you believe to be normal...
>
> Personally I only ever used it to add additional metadata to the POM. I
> think this is a pretty normal use case, certainly for OSS projects.
> Although I will say that the old DSL for doing that was much cleaner:
>
> {
> organization {
> name 'Hibernate.org'
> url 'http://hibernate.org'
> }
> issueManagement {
> system 'jira'
> url 'https://hibernate.atlassian.net/browse/HHH'
> }
> ...
> }
>
> versus now:
>
> {
> def root = asNode();
> def org = root.appendNode( 'organization' )
> org.appendNode( 'name', 'Hibernate.org' )
> org.appendNode( 'url', 'http://hibernate.org' )
> def jira = root.appendNode( 'issueManagement' )
> jira.appendNode( 'system', 'jira' )
> jira.appendNode( 'url', 'https://hibernate.atlassian.net/browse/HHH' )
> ...
> }
>
> For the appending use case, I think access to just the XML "works". I would
> prefer to see a better DSL for appending content, but thats just me perhaps.
We do want to add a DSL for this kind of customisation. The XML hook is really
just there as a workaround for things that are currently missing from the DSL.
>
> I cannot speak to any of the other use cases (remapping dependencies, etc).
> I am only touching the dependencies now because of this scope issue.
>
>
>
> On Tue 07 May 2013 08:07:52 AM CDT, Hans Dockter wrote:
>>
>>
>> On Tue, May 7, 2013 at 2:50 PM, Steve Ebersole
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> I agree that neither is correct and that this is yet another
>> manifestation of bad Maven design.
>>
>> But...
>>
>> This is a POM. It is specifically a Maven artifact. In my
>> opinion this needs to follow Maven conventions. That seems to be
>> the way you are leaning as well given the plan you are describing
>> below.
>>
>>
>> I agree although people should be able to choose I guess.
>>
>>
>> I'd really like to stick with the Publication DSL. It is much
>> simpler/better. I updated my plugins to work with it. And I'd
>> like to keep testing it for y'all. It is not clear from the
>> documentation how one can use the pom.withXml approach to
>> over-write values already in the POM from Gradle. I tried what
>> seemed logical (though granted, brute force) to me:
>>
>> pom.withXml {
>> asNode()...
>>
>> final String runtimeScope = '<scope>runtime</scope>';
>> final int replacementLength = runtimeScope.length();
>> final String compileScope = '<scope>compile</scope>';
>> final StringBuilder stringBuilder = asString();
>> int index = stringBuilder.indexOf( runtimeScope );
>> while ( index > -1 ) {
>> stringBuilder.replace( index, index+replacementLength,
>> compileScope );
>> index = stringBuilder.indexOf( runtimeScope );
>> }
>> }
>>
>> It works (though quite ugly imo).
>>
>>
>> BTW: With the wonderful old publication API you had access to the
>> Maven project object directly ;). Do we think that this is not really
>> necessary and having access to the XML representation is good enough?
>>
>> Hans
>>
>>
>>
>> On 05/05/2013 03:13 PM, Adam Murdoch wrote:
>>>
>>> On 03/05/2013, at 11:28 PM, Steve Ebersole <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>> After updating Hibernate to use the new publishing stuff we now
>>>> see all dependencies in the generated POM as 'runtime' whereas
>>>> previously the generated pom used 'compile'. Is that expected?
>>>>
>>>> If so, I understand the logic behind using 'runtime' instead
>>>> except for the fact of the footnote on Maven's own dependency
>>>> primer[1[, I quote:
>>>> " it is intended that this should be runtime scope instead, so
>>>> that all compile dependencies must be explicitly listed -
>>>> however, there is the case where the library you depend on
>>>> extends a class from another library, forcing you to have
>>>> available at compile time. For this reason, compile time
>>>> dependencies remain as compile scope even when they are transitive."
>>>>
>>>> Given that this is generating something to explicitly plug in to
>>>> Maven builds, I think 'compile' should still have been the choice.
>>>
>>> The problem is that both choices are wrong. Some of the things
>>> you compile against form part of your API, and should be made
>>> available to a consumer when they are compiling against your
>>> component. And some of the things you compile against form part
>>> of your private implementation, and should not be made available
>>> to a consumer at compile time.
>>>
>>> Our plan is to add a mechanism that allows you to declare the
>>> dependencies of your API. These will be made available to both
>>> you and your consumers at compile time. When you're publishing to
>>> Maven, these will end up in the `compile` scope. Everything else
>>> will end up in the `runtime` scope.
>>>
>>> There will also be a DSL on the publication object for messing
>>> with the scopes, if you don't like whatever the defaults happen
>>> to be. We've done this for the artefacts of the publication, but
>>> haven't tackled it for the scopes and dependencies yet.
>>>
>>>>
>>>> [1]
>>>>
>>>> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
>>>>
>>>>
>>>> On Tue 16 Apr 2013 06:11:54 PM CDT, Steve Ebersole wrote:
>>>>> That plugin code on master works. I just integrated it into
>>>>> Hibernate
>>>>> build and updated Hibernate to use this Publication DSL and was
>>>>> able
>>>>> to perform a publish!
>>>>>
>>>>> In terms of designing a generic solution, not sure how much help I
>>>>> will be. Gradle has moved on dramatically from the last time I was
>>>>> "in the code". But I do think the
>>>>>
>>>>> org.hibernate.build.gradle.publish.auth.maven.Credentials/CredentialsProvider/CredentialsProviderRegistry
>>>>> stuff is pretty generic solution for managing credentials.
>>>>> But I'd
>>>>> not really be sure the best way to tie it in to Gradle to apply
>>>>> credentials to "things" that need authentication.
>>>>>
>>>>> Anyway, I'll be pushing (ahem, *publishing*) a 2.0.0 release of
>>>>> this
>>>>> plugin later today that will support its feature set against the
>>>>> Publication DSL.
>>>>>
>>>>> Thanks to Luke, Daz and Adam for all the help getting me on the
>>>>> right
>>>>> path there!
>>>>>
>>>>>
>>>>> On Tue 16 Apr 2013 04:19:41 PM CDT, Adam Murdoch wrote:
>>>>>>
>>>>>> On 16/04/2013, at 10:41 PM, Steve Ebersole
>>>>>> <[email protected] <mailto:[email protected]>
>>>>>> <mailto:[email protected]>> wrote:
>>>>>>
>>>>>>> Maybe an even better question...
>>>>>>>
>>>>>>> This upload credential plugin is really in my opinion a work
>>>>>>> around
>>>>>>> for the fact that Gradle has no built-in support for externalized
>>>>>>> credential declaration. As the developer of an OSS project,
>>>>>>> it is
>>>>>>> utterly impossible for me to put my username/password
>>>>>>> directly into
>>>>>>> my build scripts.
>>>>>>>
>>>>>>> While forcing each project to define username/password project
>>>>>>> variables and do the whole hasProperty checking stuff
>>>>>>> "works", it is
>>>>>>> (again in my opinion) not ideal.
>>>>>>
>>>>>> Absolutely. I agree with this.
>>>>>>
>>>>>>>
>>>>>>> So... Is there any externalized credential management in
>>>>>>> place or
>>>>>>> planned? Pretty sure there is nothing in place as of now. Is
>>>>>>> anything of the sort planned?
>>>>>>
>>>>>> It's planned. Just a matter of finding the time. As always, if
>>>>>> someone
>>>>>> from the community is interested in helping out with this,
>>>>>> we'd really
>>>>>> appreciate it. One place to start would be to get Steve's plugin
>>>>>> merged into Gradle and we can evolve it from there.
>>>>>>>
>>>>>>>
>>>>>>> On Tue 16 Apr 2013 07:30:57 AM CDT, Steve Ebersole 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?
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue 16 Apr 2013 07:25:04 AM CDT, Luke Daley wrote:
>>>>>>>>>
>>>>>>>>> On 16/04/2013, at 1:19 PM, Steve Ebersole
>>>>>>>>> <[email protected] <mailto:[email protected]>
>>>>>>>>> <mailto:[email protected]>> 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
>>>>>>>>>>> <[email protected] <mailto:[email protected]>
>>>>>>>>>>> <mailto:[email protected]>
>>>>>>>>>>> <mailto:[email protected]>> 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
>>>>>>>>>>> <[email protected] <mailto:[email protected]>
>>>>>>>>>>> <mailto:[email protected]>
>>>>>>>>>>> <mailto:[email protected]
>>>>>>>>>>> <mailto:[email protected]>>>
>>>>>>>>>>> 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
>>>>>>
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>
> ---------------------------------------------------------------------
> 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
