Quarkus: Make gradle plugin available for easy/conventional gradle usage

[maxandersen]

Today we need a lot of scaffolding in users gradle setup:

plugins {
    id 'java'
}

apply plugin: 'io.quarkus'

pluginManagement {
    repositories {
        mavenCentral()
        gradlePluginPortal()
    }
    resolutionStrategy {
        eachPlugin {
            if (requested.id.id == 'io.quarkus') {
                useModule("io.quarkus:quarkus-gradle-plugin:${requested.version}")
            }
        }
    }
}

where if we published to gradle registry users would just need this:

plugins {
    id 'java'
    id 'io.quarkus'
}

for now it is assumed we must make the gradle plugin an actual gradle project to make this happen - need to verify that

[geoand]

I think the gradle plugin does indeed need to be a gradle project, if not for any other reason than the fact that the necessary build tool plugins that would allow publishing to the Gradle Portal only exist for gradle.

[maxandersen]

duplicate of https://github.com/quarkusio/quarkus/issues/1793

[cniweb]

+1

[Sanne]

@maxandersen Gradle plugins can decorate other plugins; the goal should be to require users to just

plugins { id 'io.quarkus' }

(the 'java' plugin should be unnecessary - unless there's need to differentiate for the Kotlin projects but I think that could be skipped or handled as a different plugin id)

[Sanne]

example of a full build scripts - as in the POC I shared a while back with the team:

plugins { id 'io.quarkus' }

quarkus {
  version = ''
}

extensions {
  'io.quarkus.hibernate',
  'io.quarkus.resteasy',
  'io.quarkus.mariadb'
}

In other words: the full coordinates of extensions are also redundant, and the build tools could actually take advantage of this so to treat the dependencies-declares-as-extensions in a more efficient way.

Also, it makes it redundant to pick extension versions. the quarkus version block could be optional, defaulting to latest, or to the version matching the plugin version.

[gastaldi]

My user doesn't have permission to push to the portal. Since this is part of the release process, I am assigning this issue to @gsmet . The Gradle plugin is all set to be published, all that's left is the API key and secret with permission to publish the io.quarkus plugin. See https://github.com/quarkusio/quarkus/issues/1793#issuecomment-523654527

[gsmet]

I got no feedback from the Gradle Portal team. Sanne said that we would need the plugin to be in its very own repo so we apparently would need to move the plugin out of the tree to its own repo. I'm unassigning myself from this as I don't really see how I can help for now.

[gastaldi]

I'll reassign the issue to myself and look into that. Is it OK if I create a separate repository in the quarkusio org and move the Gradle plugin sources there?

@Sanne forgive me if I am mistaken, but I may have heard you mentioned that you had permission to push the plugin to the portal? Everytime I do that by following the steps in the Gradle Portal I also, like @gsmet, get an authorization error.

[aloubyansky]

@gastaldi fyi, i have platform/tools related changes to the gradle plugin dependencies.

[Sanne]

forgive me if I am mistaken, but I may have heard you mentioned that you had permission to push the plugin to the portal?

@gastaldi no I don't think I have permissions to deploy this plugin. I have a working account, which I use regularly to publish _other_ plugins. So I can share my experience but I doubt I would have more luck with this plugin as the authorization is specific to each plugin, and needs to be granted first.

[gastaldi]

Plugin available in https://plugins.gradle.org/plugin/io.quarkus Right now I, @gsmet and @cescoffier are the plugin owners, may add more if necessary (through the Gradle maintainers directly)

[aloubyansky]

@gastaldi did you extract the gradle plugin module to its own repo?

[gsmet]

No, it was pushed from the main repo.

If there's no strong reason to extract it, we can keep it the way it is.

[aloubyansky]

Ok, thanks!

[patoessy]

Thanks all for this.