Closed fourlastor closed 5 months ago
I think adding a plugin marker artifact is the right way to go, I don't see any downside of it.
Regarding the java-gradle-plugin
, I looked through it and it states but only if the [Plugin Publishing Plugin](https://plugins.gradle.org/docs/publish-plugin) has also been applied.
, so I think further configuration is still needed?
In any case, I would have no real objections against the java-gradle-plugin
, if it is backwards compatible, but as I understand it it isn't really relevant for publishing the marker artifact, right?
I think the extra config wasn't needed in the end (the publish plugin is applied from publishing.gradle
), sorry for the long wait!
jnigen doesn't currently use a plugin marker artifact as it doesn't use the java-gradle-plugin which would automate this task.
In the kotlin gradle DSL this means that the
jnigen
extension won't be available, and if the plugin is applied with the current readme instructions, it will require this to be configured:A workaround for this is to declare custom plugin resolution rules:
Then, the plugin can be applied via the
plugins
block in thebuild.gradle.kts
file, andjnigen
will be available as an extension:I don't think either is optimal, but it could be useful to explain it in the readme file. An alternative (which imho would be better also for
.gradle
files) would be to actually use thejava-gradle-plugin
so that the plugin will be published correctly.I'd be happy to make a PR for either solution, let me know if that's something you'd be interested in!