В central?

Да

А зачем, если дефолтное место для них - plugin portal?

Мой плагин по сути является обёрткой для другой моей либы, которая уже в мавене. Вот я и подумал что им хорошо было бы лежать вместе.

Мне кажется, это ни к чему.
Центральное место для плагинов другое. И там его будет видно на plugins.gradle.org, да и публикация проще

Хорошо, спасибо. Наверное так и сделаю.

не не не. Не слушайте тов. Владимира П. Публикуйте в Central — это очень плезно и хорошо. Без шуток.

Я бы предложил добавить

        configure<PublishingExtension> { // publishing
            publications {
                afterEvaluate {
                    named<MavenPublication>("pluginMaven") {
                        config() // донастройка license и т.п. для plugin артефакта
                    }
                }

Но и функцию fun MavenPom.config я бы предложил назвать более конкретно, ведь config это слишком общее название — по нему неясно что там делается.

Пояснение бы к этому ещё :)

Всё кроме плагинов я и так туда публикую. А плагин пусть там и лежит.

1) В Central можно публиковать PGP-подписанные файлы. Пользователи dependency verification скажут спасибо.  Я не говорю, что PGP это идеал, но, к сожалению, sigstore пока не вышли в эксплуатацию.

2) В Central можно публиковать staged версии (грубо говоря, staged repository, у которого свой адрес, но который можно либо выкатить в release, либо удалить). Например, я могу сделать release candidate, и пробовать его в других проектах, смотреть как оно. Из GPP, конечно, можно удалять версии, но у меня *много* раз было, когда не получалось удалить версию из GPP

Плагины, которые опубликованы в Central идентичны натуральным. Ну, по факту, я свои плагины дублирую в Central и в GPP.
Если GPP падает (иногда публикация туда отваливается), то опубликовынный в Central спасает (т.к. GPP прозрачно проксирует в Central)

3) Указание лицезнии — лишним не будет. Сейчас же получается, что из GPP приходит plugin-bla-bla-pom.xml, в котором не говорится о лицезнии на него. Это крайне печально.
По-хорошему, в каждом файле должно быть указано то, на каких правах им можно пользоваться.

Поэтому, требование Central про обязательность блока license это не пустой звук.

Вот issue, в котором Jendrik предлагает способ кастомизации pom.xml, который генерирует gradle-plugin-plugin: https://github.com/gradle/gradle/issues/17022#issuecomment-836482860

Я ещё проверить не успел

Это всё хорошо, но мне всё равно. :) Главное чтобы легко запаблишить и начать юзать.

@vladimirsitnikv спасибо за развёрнутый ответ!

Тогда «самый главный аргумент»: когда публикуешь в GPP, то там первый раз плагин могут неделю-две «проверять».
А создание координат на Central — пара минут. Там полная автоматизация.

Вот пример: https://issues.sonatype.org/browse/OSSRH-55087
Я создал тикет: «Дайте права выкладывать в group=com.github.vavrcc»

Посмотрел на номер тикета, и создал реопзиторий с таким же именем на github (ну, если так не сделать, то робот попросит, но тут я был быстрее)

Через 7 минут Sonatype робот убедился, что у меня реально есть права на github.com/vavrcc и отписался, что всё готово.

А код для обычной публикации удалить?

оставить

для отладки я бы предложил publishToMavenLocal — и в .m2/.. можно поглядеть какие xml-ки сгенерировались