This message was deleted.
# plugin-development
s
This message was deleted.
m
I could make a wrapper plugin but that's a lot of hoops for nothing?
t
“lot of hoops” as in creating a one-liner class that
apply(com.example.Plugin.class)
?
😂 2
m
Yes 🙃
And adding the
gradleApi()
dependency
I guess the point I'm trying to make is that I'm ok with this being a warning but I don't see a reason to make it an error?
c
You are publishing a plugin from your project, but the plugin is not in your project?
m
It's in a separate module
I have 3 modules: • plugin-core: contains the actual code • plugin-external: depends on plugin-core and packaged as external • plugin-shadow: depends on plugin-core and packaged with relocated dependencies
I kind of like the idea that both
plugin-external
and
plugin-shadow
are "empty shells"/"redirect" to the actual plugin code
c
But then you are publishing jars of the plugins and you want to publish the markers from another module
m
I think so? I'll have 2 markers
c
It seems weird. I mean, is you had a fatJar (including the 3 modules) it would be fine. 1 jar - one module publishing markers But right now you have 3 modules publishing jars and only one publishing all the markers
m
Both
plugin-external
and
plugin-shadow
should publish the markers
They'd have different plugin ids
c
( I said everything "wrong" because I didn't read your reply first)
m
Yea and actually
plugin-shadow
wouldn't be an "empty shell" at all because it would be very fat (well, it would be an almost empty project but once published, it should publish the fat jar, sorry for the confusion)
But
plugin-external
would
c
So for plugin-shadow you don't have this issue
m
Indeed 👍
That's only for
plugin-external
c
And maybe you could publish plugin-external marker from plugin-core then
m
But if the plugin descriptor ends up in
plugin-core.jar
, it would make it possible to pull the
plugin-shadow.jar
in the buildscript classpath and still apply
com.example.external
, which could be missleading
Not the end of the world, I agree
c
I think your use case is very uncommon, and understand that gradle is making the right thing, that said.. it's annoying for you, it's true
👍 1
m
Ideally I would publish a single publication with multiple variants but I haven't found a way to easily choose a plugin variant on the consumer side