On 7 May 2013 23:07, Hans Dockter <hans.dock...@gradleware.com> wrote:
>
>
> On Tue, May 7, 2013 at 2:50 PM, Steve Ebersole
> <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?
>
No, we don't think that it's good enough. It simply makes it possible to do
things that we haven't yet made it convenient to do.
>
> Hans
>
>
>>
>> On 05/05/2013 03:13 PM, Adam Murdoch wrote:
>>
>>
>> On 03/05/2013, at 11:28 PM, Steve Ebersole <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
>>
>>
>> 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 <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 <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 <st...@hibernate.org>>
>> <mailto:st...@hibernate.org <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 <st...@hibernate.org>>
>> <mailto:st...@hibernate.org <st...@hibernate.org>
>> <mailto:st...@hibernate.org <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
>>
>>
>>
>> --
>> 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
>>
>>
>>
>
--
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
