Publish source and javadoc jars for Gradle to maven central


(Justin Ryan) #1

When writing plugins, I routinely need access to the Gradle sources/javadocs in my IDE. I’m using Intellij, which would be happy to just download the sources from oss.sonatype.org. Assigning each library with it’s specific directory in gradle/subproject is prohibitive via UI. The alternative seems to be to import Gradle as a project into the IDE, which isn’t my preferred way to work given that I already have a few modules open.

Likewise, the Tooling API is meant to be used outside a Gradle install so it really should be available in Maven Central.


(Peter Niederwieser) #2

+1 from my side. Having Gradle Jars (code+sources+javadoc) in Maven Central would make life easier for plugin authors.


(Justin Ryan) #3

I should mention that this a loaded question. The release process from gradle is non-existant right now, and if Gradle started to release their libraries to Maven Central, at least then the Gradle devs would feel our pain.


(Peter Niederwieser) #4

The release process from gradle is non-existant right now

What do you mean by that?


(Justin Ryan) #5

Sorry I should have been more clear, and maybe I’m missing something. The maven release plugin has a drawn a nice line in the sand for what people expect when they need to “release”. “Release” involving building/signing/sending to sonatype, maybe staging everything then most importantly revving the version. The first half if pretty well covered, if you poke around the internet enough, but even then you’ll have some warts setting the right keys and sonatype login. Staging locally take some more coding, but it can be done (read: not implied from convention, you have to be very explit that you want a different repo locally and create a new upload task).

The key though is finding the appropriate next version and using that, changing the version in SCM and possibly tagging the release in SCM. You should also be able to differentiate between release and snapshot. You can see hints of it in the Gradle source tree in buildSrc, e.g. Releases.groovy, Tag.groovy, or in the Artifactory plugin. But, from what I can tell, this isn’t made available to users.

I’d challenge someone to show a realistic minimally viable gradle “hello world” project that releases to Maven Central, and it won’t be under 200 lines. And that seems like way too much when we’re all trying to do it the same way, it’s almost prohibitive. I can see people coming to Gradle and saying “This looks great”, and then when they’re done releasing they realize that this is more than they signed up for. The appropriate answer might be plugins. I just haven’t seen a plugin the does all that with reasonable defaults, which we might have seen from Maven.

I hopeful that this will exist, soon, though I believe the pain of developing plugins is preventing the community from offering a rich set of powerful plugins.


(Peter Niederwieser) #6

You may want to have a look at the Gradle Release Plugin. I’m sure they would also appreciate contributions.

The Jenkins Artifactory Plugin provides full release management for Gradle builds.

Even without a release plugin, I don’t find publishing to Maven Central that hard for my project (http://github.spockframework.org ). I currently do the version update/SCM work manually, but it doesn’t take more than a minute. The switch from rsync to Sonatype OSS repository has certainly increased the level of manual work; not sure if there is a way around that.


(Justin Ryan) #7

WIth manual intervention it possible out of the box. I help all our open source projects with their release and telling them that they can’t using Jenkins and they have to manually do something which the previously had done with maven has been a hard sell. I use a lot of similar conventions as you do, but it feels “wrong” when I copy it to a dozen projects.

I think a minimal viable “hello world” project which releases via CI would expose a lot of warts people are experiencing.

BTW, we LOVE spock. If you’re ever in Silicon Valley, we’d be happy to have you give a talk at Netflix.


(Peter Niederwieser) #8

Have you tried the Gradle release plugin or the Jenkins Artifactory plugin? In what ways are they worse than their Maven counterparts? Is it possible to do a fully automated release to Maven Central with Maven?


(Justin Ryan) #9

Releasing from Jenkins isn’t in option, we feel that the build tool needs to be able to do orchestrate everything. I’ve evaluated the release plugin and don’t remember it being able to do everything, I will look at it again this week. Going through oss.sonatype.org does still require logging in and pushing it out from the staging area.

The point of the post still is that code+source+javadoc should be in maven central.


(Michael Ekstrand) #10

+1. I am embarking on on integrating Gradle into the LensKit toolkit (it will mostly serve as a plugin for Gradle, but possibly also a custom CLI front-end or distribution that includes our code). For initial development, I’m pulling from repo.gradle.org, but that isn’t a viable solution long-term since we publish to Maven Central and they prohibit external repository references.

We would very much like to avoid pushing a copy of Gradle under our own group ID (which is my current backup plan if Gradle doesn’t make it to Central before we need to release).


(Peter Niederwieser) #11

Gradle won’t be published to Maven Central anytime soon. Only the Gradle wrapper and tooling API are published to repo.gradle.org. Plugins are expected to be built with Gradle (even more so in the future) and shouldn’t have any Gradle dependency declarations in their POMs. Gradle is effectively a ‘provided’ dependency.

Sorry that I don’t have any better news.


(Francis Galiegue) #12

I don’t really understand where the difficulty is here.

I mean, releasing all relevant artifacts to Sonatype has been doable for more than a year: http://jedicoder.blogspot.fr/2011/11/automated-gradle-project-deployment-to.html

And gradle is self hosted, right? So, publishing gradle this way should not be a problem at all…


(Luke Daley) #13

Publishing is not the problem. Gradle uses the physical structure of the distribution to inform the classloader partitioning during bootstrap.


(Justin Ryan) #14

My interest in having Gradle published with sources is for plugin development. I want to be able to open any plugin from GitHub or internally, and get Command-Click functionality on Gradle classes in my IDE. The IDE’s know where to look in Maven Central to find the source, if it existed.


(Francis Galiegue) #15

I was actually thinking exactly the same thing!

Not sure the context made it clear. But I endorse that completely.

A gradle-api jar maybe?


(Luke Daley) #16

I’m not aware of any IDE that automatically fetches the source JAR. Which ones do? and how does it work?


(Francis Galiegue) #17

I’m not aware of any IDE that automatically fetches the source JAR. Which ones do? and how does it work?

IDEA (12+ at least; probably older versions as well) does, that’s for sure. As @JustinRyan says, it knows what to look for. Probably relies on the classifier, I don’t know the details. It even fetches Javadoc.

When you initiate a maven project, you are even given the option to fetch them automatically or not. Since I switched to gradle I didn’t even need to tell it, it just does it… Probably grabs its configuration from the Maven project configuration where I told it to do just that.


(Luke Daley) #18

For Gradle integration at least, it’s Gradle that is doing this… not IDEA.


(Francis Galiegue) #19

That is not how it happens with IDEA. From what I could understand, if it recognizes a dependency, it looks up the matching documentation and sources using its Maven support.

We are talking about plugin development here. If there is a gradle-api dependency which is available and that plugin has sources/javadoc jars, IDEA will fetch them even if you don’t tell gradle to do so. Works every time for me.

I recently started a gradle-only project and asked it to use jackson-databind-2.2.2: IDEA has automatically fetched the documentation and javadoc for me before even “gradle compileJava” because it recognized the dependency and acted the way I told it to.


(Luke Daley) #20

How did you get the project into IDEA?