Adding License Specification to Gradle Plugin Publishing

I am trying to use the plug-in portal to publish plug-ins for the first time. I followed the guide at https://guides.gradle.org/publishing-plugins-to-gradle-plugin-portal/, and uploaded successfully.

However, they are now marked as “pending approval”, and after doing some research I found something here in the forum (Plugin pending approval) that indicates plug-ins are highly encouraged to provide a open-source VCS URL and license. I specified the VCS (that part is in the example in the guide), however I cannot find information on how to specify the license (the plug-in is under MIT but I don’t know how to provide that info to the plug-in portal upload). Before using plug-in portal, I used the pom customization of MavenPublication to do this. I’ve tried looking for guides or the pluginBundle DSL to see if it exposes something, but cannot documented use of either.

Also, if I figure out how to do this, can I simply re-run the publish task to re-upload with the new info?

Any guidance would be greatly appreciated!

We usually infer the license from the VCS link. If it’s a GitHub repository, then having a LICENSE file that GitHub understand is usually enough. There is no official process that I’m aware of. Associating your GitHub profile also help with the approval process to weed out the potential spam account. There is a backlog of plugins in the approval process given the imminent 5.6 GA release. We should be able to process them soon.

Thank you, that helps clarify the requirements quite a bit. The plug-ins I was waiting on have been approved at this point, I mainly just wanted to make sure I was following best/correct practices for specifying such information.

Out of curiosity, why is the plug-in publishing setup not backed by the “standard” publication mechanism/DSL (via adding a publication that is uses, and can be modified by clients in the same way a standard publication can be). What led to the design we currently see in that regard?

That is a great question. It’s a lot of decision that result in what we currently have. The main one is plugin availability. Owning the plugin binary allow us to ensure it won’t get removed under our feet. There’s other way we could have implemented a solution for this. Back then, the software publication was a bit different than today. We may revisit this in the future.