Publishing to the Plugin Portal via Artifactory

[Andy_Wilkinson (awilkinson)]

@tomd

Not really at this point. Longer term we’ll implement some sort of staging workflow, or at the very least a sandbox plugin portal, but we’re not there yet.

That’s good news. Thanks.

@tomd

Without actually running the command, you could print out the files associated with each archive to be uploaded, which are defined by the archives configuration:

…

To ensure that you don’t upload a jar that you don’t want to get generated on that run, you could stick in a TaskExecutionListener that fails when the tasks are run. Something like:

…

This is starting to feel rather brattle and, particularly without any staging mechanism, it makes the risk of uploading a plugin to the Portal start to outweigh the benefits.

@tomd

While I understand wanting that, the pom is considered an implementation detail for plugin resolution. We use poms for dependency information more for compatibility with Bintray which we were using for hosting than anything else. The Gradle plugin repo shouldn’t be used by any other consumers, and we don’t really expect poms in there to be used for the more general metadata that people put in them for publishing to general public repos. We may even change the implementation to generate poms with the correct dependency information on the fly at some point. So we won’t be adding the ability to use a custom pom or customise the one that gets generated - we’d rather that people don’t think about there being a pom in there at all.

I don’t think the pom can be considered an implementation detail as it leaks out in some obvious places. It’s apparent from the m2 in the plugin repository’s url (https://plugins.gradle.org/m2/) that Maven and therefore a pom is involved. Users can also see log messages for a pom being downloaded when the plugin isn’t already cached locally.

I also have a more general concern about what should be the same artifact being in different repositories with different metadata. If a user reports a problem with the plugin that could be caused by a faulty pom (perhaps a dependency is in the wrong scope), I don’t what to have to ask how the plugin was installed to know which pom will be involved.

Another point in favour of allowing plugin authors to provide their own pom is that it means that the automatic pom generation doesn’t have to understand things like jarjar. Perhaps it already does? However, providing an escape hatch that allows a user to specify their own pom would appear to be more robust as it gives the plugin author complete control when needed.

I think it’s a shame that the new approach replaced the old approach. While it is undoubtedly simpler, that simplification has come at a cost that’s too high for us. Could the old approach be run in parallel for plugin authors with more sophisticated requirements? It worked very well for us, providing all of the control and safeguards that are missing from the new plugin-based approach.