On 7 May 2013 23:26, Steve Ebersole <steven.ebers...@gmail.com> 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<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<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.
>
While it's a little hacky, Groovy gives a pretty nice way to do this:
pom.withXml {
asNode().children().last() + {
organization {
name 'Hibernate.org'
url 'http://hibernate.org'
}
issueManagement {
system 'jira'
url
'https://hibernate.atlassian.**net/browse/HHH<https://hibernate.atlassian.net/browse/HHH>
'
}
}
> 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
>> <steven.ebers...@gmail.com
>> <mailto:steven.ebersole@gmail.**com<steven.ebers...@gmail.com>>>
>> 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 <st...@hibernate.org
>>> <mailto:st...@hibernate.org>> 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<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
>>>>>> <st...@hibernate.org <mailto:st...@hibernate.org>
>>>>>> <mailto:st...@hibernate.org>> 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
>>>>>>>>> <st...@hibernate.org <mailto:st...@hibernate.org>
>>>>>>>>> <mailto: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<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<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>
>>>>>>>>>>> <mailto: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>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> <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>
>>>>>>>>>>> <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
>>>>>>>>>>> <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<http://xircles.codehaus.org/manage_email>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>> ------------------------------**------------------------------**
>>>>>>> ---------
>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>
>>>>>>>
>>>>>>> http://xircles.codehaus.org/**manage_email<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<http://xircles.codehaus.org/manage_email>
>
>
>
--
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
