Extending repositories{} to accommodate publishing to Bintray. DSL suggestions


(Schalk Cronjé) #1

Publishing to Bintray as an Ivy or Maven repo are pretty easy as can be seen at

https://t.co/WJx8J66WAZ (Rob Fletcher’s Compass)

and at the top of my Gist.

This however, relies on the package metadata being created manually on the bintray before upload or running a task from gradle to do this, something which I currently have in my buildSrc.

http://t.co/tAQTJ647Cg

I am looking to create a proper plugin that can take care of the package creation metadata and the publishing.

Returning to the Gist listed earlier, I have two DSL proposals for doing this. I am actually not even sure how to implement it, but I think it is good to get the DSL right and then worry about the implementation. Any feedback on the DSL would be great and indeed any suggestion of creating a better way of doing it, even better.

P.S. Something done purely for downloading exists at https://bitbucket.org/davidmc24/gradle-bintray-plugin/src/6adc1aca5ed712b8802fe6b3830b2d860d9fda88/Bintray.gradle, but not as a full plugin.


(David M. Carr) #2

I’m the author of the davidmc24 Bintray plugin. I originally pursued writing it as a full plugin, but ran into a bootstrapping issue. You can declare a regular repository and classpath entry for a full plugin in the buildscript section to extends the repositories DSL for the main build. However, this technique doesn’t allow for extending the repository DSL for the buildscript section, for example to load other plugins. Since my plugin was intended mostly as an interim measure until Gradle has built-in first-class support for Bintray, I was willing to compromise on it being a “normal” plugin in order to be able to support use in the buildscript section.

As you say, my plugin doesn’t currently support publishing. It’s on my wishlist of features, but not something I’ve devoted any real time towards yet. I did an initial evaluation of the areas of the DSL to hook into (around the timeframe that 1.5 was still under development), and decided that I wanted to wait until the new publishing mechanism was a bit more stable before I built on top of it. If you might be interested in building on top of my plugin, pull requests are welcome.


(Schalk Cronjé) #3

@David, I originally started by attempting to fork your code, but I found another approach of achieving uploads. Having spoken to Luke Daley at Gr8Conf last week, the suggestion was to extend the current upload mechanism first before workng on the new publish mechanism.

I have subsequently managed to get this to work and should have the code up on github and bintray shortly.


(Schalk Cronjé) #4

I have uploaded release 0.0.9 to bintray, but I would really appreciate a code review though - code is in this folder

https://github.com/ysb33r/Gradle/tree/RELEASE_0_0_9/bintray/src/main/groovy/org/ysb33r/gradle/bintray


(Luke Daley) #5

It’s generally not a good idea to use metaClass additions as it’s a very easy way to leak memory (due to how this is implemented in Groovy).

It would be better to create an extension class and create an extension of this type on the repositories container…

uploadTask.repositories.extensions.create(“bintray”, BintrayRepositoriesExtension)


(Schalk Cronjé) #6

I have fixed that elsewhere where it was done in that way, but not yet in the Bintray plugin. I am holding back to see what is happening with Bintray’s own plugin for Gradle they are planning to release.