https://gradle.com/ logo
Join Slack
Powered by
When I have a conventional plugin and publish it i...
# community-support
b
When I have a conventional plugin and publish it into a local maven repository. Another project wanting to use that plugin needs to include it as dependency, right?
Does that look right?
Copy code
plugins {
    java

    id("my-convention")
}

repositories {
    mavenLocal()
    mavenCentral()
}

dependencies {
    implementation("com.example.tools:my-gradle-convention-plugins:0-SNAPSHOT")
}
v
If it is published properly including marker artifacts, you just need to add the repository as plugin repository and then it should be found. But be aware that using 
mavenLocal()
is almost always a bad idea as it is broken by design in Maven already and you should at most use it as last in the list of repositories and optimally with a repository content filter if you need it at all. To just the current state of a plugin in a local project, it is usually better to use a composite build instead of publishing the plugin to a local maven repository.
Does that look right?
No, besides the problems with 
mavenLocal()
I just mentioned, you add the plugin as production dependency for your project, that might be correct if that project is building another Gradle plugin that uses that plugin, but not if you want to apply that plugin.
Also, plugin IDs should better always contain a namespace (a dot somewhere) as plugins without namespace should remain reserved for built-in plugins.
Especially if you want to publish is somewhere
b
So for more context I have 10+ applications which have almost an identical build.kts I want to centralize that information somehow.
mavenLocal() is just for testing purposes.
v
Yes, as I said, for testing purposes it is usually more convenient to use a composite build, as then you don't need to "change plugin -> publish locally -> test in the project" but you can just "change plugin -> test in the project" as it is automatically built if necessary and you also get both projects opened in the IDE automatically.
If the Gradle versions of the plugin and the project are compatible that is, optimally they are the same.
b
Where is that marker artifact located?
v
<plugin id>:<plugin id>.gradle.plugin:<plugin version>
b
I guess I understand that it might be better to have it within a structure which does not need invocation in publish, but in the end I guess I need to publish it somewhere to use it in my projects, right? Normally I publish my artifacts in a gitlab (maven) repository. I though I could do the same with the conventional plugin and use it in the other projects like my other artifacts.
just for whole reference: my testing plugin: build.gradle.kts
Copy code
plugins {
    `kotlin-dsl`
    `maven-publish`
}

group = "com.example.tools"
version = "0-SNAPSHOT"
src/main/kotin/com.exampl.tools.my-convention.kts
Copy code
tasks.register("hello") {
    println("Hello from convention plugin")
}
v
I though I could do the same with the conventional plugin and use it in the other projects like my other artifacts.
Yes, you can do that, no problem. Just for testing it is much more convenient to use a composite build instead of 
mavenLocal()
.
b
So if I get you right that marker artifact should be present in the maven repo as well.
v
Yes, if you just do a publish / publishToMavenLocal , those should automatically be published alongside, the plugins you apply take care of that for you
b
I guess that the point why it's not working for me as it seems these marker artifacts are missing.
v
No, from what you showed it does not work because you added a production dependency on the plugin artifact instead of adding 
mavenLocal()
as plugin repository and because your plugin ID does not match.
But I really recommend using a composite build for local testing instead. 🙂
b
If I have it as composite build I need to extract it anyways later on.
v
Why "later on"? You already have it extracted. The only difference is whether you call 
publishToMavenLocal
and add 
mavenLocal()
as plugin repository in the consumer, having more effort from then on, or whether you add an 
includeBuild
call to the setting script of the consumer and everything just works more conveniently.
b
I though you're talking about that 
buildSrc
folder
v
Actually, you don't even need to modify the consumer as long as you are building from commandline but can use 
--include-build
there, but it is better for IDE support to do it in the settings script
No, 
buildSrc
is not an included build at all
To great lengths it behaves very similar to an included build, but it is always special and different in nuances
b
include("app", "../my-gradle-convention-plugins")
like this
v
No, that is adding a subproject
You want a composite build where you include a whole build using 
ìncludeBuild
as I mentioned. And as it is about a Gradle plugin, within 
pluginManagement { ... }
I recommend you are not blindly trying things out and ask, that you have a look at the documentation, I gave enough significant search terms, you are not a help-vampire, are you? ;-)
b
I did not want to use 
includeBuild
😛
v
Why?
It is exactly the most appropriate and most convenient tool for your situation
It is like saying "I used Maven because I did not want to use Gradle". It is a perfectly valid PoV, you just hurt yourself with following it. 🙂
😆 1
b
From my understanding I need to deploy that plugin later on to a maven repo anyways. So if it's mavenLocal or mavenAnywhereElse seems to be most likely the same. But maybe I just don't get it fully.
But I give includeBuild a try and see if it works.
v
If it works with publishing, it works with composite build in practically all cases. The only difference is a better quality of life for the developer, that is you. 🙂
b
My initial problem was that publishing and using does not work and I tried to figure out why it does not.
v
And I told you why 🙂
That I recommended a way better way to test your plugin is separate from that
b
I don't know it seems to be too complicated for me. I cannot figure out how that id is defined and I'm also uncertain if a conventional plugin is the same as a gradle plugin.
Anyways. Thanks for help and beeing patient.
v
A "conventional plugin" is just a Gradle plugin employing your conventions like applying other plugins and configuring those plugins, no matter how you implement it. What you actually mean when you say "conventional plugin" is called "precompiled Kotlin DSL script plugin", and yes, the result is just a Gradle plugin like any other. What is too complicated for you? Getting it running with 
mavenLocal()
or getting it running with composite build? The latter is actually much easier then the former.
I cannot figure out how that id is defined
The ID is the file-name minus the 
.gradle.kts
so from what you showed, the plugin ID is 
com.exampl.tools.my-convention
Well, it would be, if your file would be named properly
Currently you do not have any plugin defined at all, you just have a Kotlin script file
Just have noticed now that you miss the 
.gradle
in front of the 
.kts
Which then also explains why there is not Plugin Marker Aritfact, as there is no Plugin 🙂
b
And I need to use plugin java-gradle-plugin I guess?
now: 
com.example.tools.my-convention.gradle.kts
👌 1
v
And I need to use plugin java-gradle-plugin I guess?
No, the 
kotlin-dsl
plugin already applies that for you
b
Ok. I guess that's the marker artifact: 
.m2/repository/com/example/tools/my-convention/com.example.tools.my-convention.gradle.plugin
v
Exactly
b
ffs it's working
👌 1
thanks!
v
Now switch to composite build 🙂
b
I already did
👌 1
Open in Slack
PreviousNext
Powered by