On 7 May 2013 22:50, 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'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).
>
Not sure why you're using string manipulation for this. It would be
clearer to use Groovy's XML support, I think:
asNode().dependencies[0].dependency.each {
it.scope[0].value = 'compile'
}
>
>
> 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
