This message was deleted.
# community-support
s
This message was deleted.
🧵 1
j
Okay, I was setting the group incorrectly - now it’s set properly, and I’m seeing deployment in
~/.m2/repository/com/foo/bar/gradle-plugin/1.2.6/*
- but using a plugin with those coordinates (
id("com.foo.bar.gradle-plugin") version "1.2.6"
) is failing to resolve - how would I specify the name properly?
j
the id is not based on the artifact coordinates, you need to set it explicitly with the Gradle plugin
j
well, using the id from the plugins { create {… }} block isn’t working either
j
Have you added
mavenLocal()
to the
pluginManagement
,
repositories
block?
j
yes
j
Which task are you calling to publish it locally?
j
./gradlew publishPluginMavenPublicationToMavenLocal
j
Call
publishToMavenLocal
and try again
Probably you are not publishing the marker artifact for that ID
j
and that fixed it. What the heck.
Two artifacts are published, the normal one plus one associated to the ID, you can see the folder if you check the m2 tree
j
Yeah, I saw it
Should I expect
./gradlew publish
to do the right thing, then?
👍 1
I was doing too much specific invocation?
👍 1
j
I haven't tried to run
publish
, but if you want to know what it is calling, you can do
./gradlew publish --dry-run
and check if it is calling
publishToMavenLocal
But take care, maybe it can be publishing the plugin everywhere (MavenCentral, MavenLocal, whatever). So I would check it with
--dry-run
to avoid a big problem
j
Well, our actual repository requires access from circleci, so I can’t REALLY break it, but yeah
r
./gradlew publishToMavenLocal
I save time by typing
./gradlew pTML
v
publish
is doing the non-maven-local publishing
publishToMavenLocal
is doing the maven-local-publishing both do "the right thing", depending on all the worried publishing tasks that are relevant