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>> 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>> 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> >>>>>>>> <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 >>>> >>>> >>> >>> >>> -- >>> 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
