Why write another plugin for publishing to Maven C...
# community-news
y
Why write another plugin for publishing to Maven Central if there are already a number of them? At one time there were 18 plugins listed on the Publishing By Using a Gradle Plugin page. The reality was that the ones we investigated did not do what we required for the YSF. We would have preferred to use JReleaser, but it leaks far too many dependencies onto the plugin classpath, which makes it incompatible with some other plugins. We then decided to try nmcp, as we know some of the authors, but we found a limitation and even the authors recommended using the vanniktech plugin. The latter is really a great plugin plugin and in reality is the one to use when one needs Kotlin Multi-platform support. But for us it did too much - we needed something simpler. We also looked at a number of other plugins, including offerings DanySK, deepmedia, and yannanhub, but all of these plugins suffered from various shortcomings. So here we go, we released the Nempi plugin and it is: • Fully automated release by default. • Compatible with isolated projects. • Compatible with configuration cache. • Ability to have access tokens securely stored. • No hardcoded property names which could clash with other plugins. • Handle single project and multi-project layouts correctly. • As per typical Sonatype practice, pushes all artifacts in a single ZIP file. See the docs at https://nempi.ysb33r.org. (Plugin ID is
org.ysb33r.nempi
) If your project is the classic write a JVM-based code-base, make a JAR and publish to MavenCentral, then this might just be a plugin that works well for you too.
🎉 1
t
nice! Does it handle javadoc and source jar creation and publishing as well? That's something I like about vanniktech. And what about Kotlin/dokka—is this just for Java projects?
2
p
I also created a very simple publishing plugin that only publish and nothing else 🤷🏻‍♂️
The new api is too simple
y
nice! Does it handle javadoc and source jar creation and publishing as well? That's something I like about vanniktech. And what about Kotlin/dokka—is this just for Java projects?
@tony It is primarily meant for straightforward Java/Groovy/Kotlin/Scala projects where you build a JAR and want to publish it to MavenCentral. It does the boilerplate work of adding in signing (if you supply in-memory keys) and creating publications. It does not have direct support for Kotlin/dokka. It also does not (and will not) support Kotlin-multiplatform -
vanniktech
is still the way to go for that. An example of what was published using nempi: https://repo1.maven.org/maven2/org/ysb33r/gradle/grolifant5-herd/5.9.0-alpha.1/ (You need to wire in sources & doc JAR inclusion via the standard
java
extension).
I also created a very simple publishing plugin that only publish and nothing else
@Philip W Nice, it does do classpath isolation, How does it handle uploading in a multi-project setup?
p
It creates a zip file for each module individually.
It has one downside, in case of an error in some artifacts/uploads, you need only to upload the failed ones
But uploading in parallel is incredibly fast because Gradle can build the modules independently.
👍 1
b
One of the issue with the vanniktech plugin is the support of
shadowJar
, and this plugin makes it really difficult to support this.
> We would have preferred to use JReleaser, but it leaks far too many dependencies onto the plugin classpath, which makes it incompatible with some other plugins. 200% true, I spent quite sometime trying to avoid issue with JGit for example.
> but we found a limitation and even the author @ysb33r What was the limitation of nmcp ?
y
@Brice Dutheil At the time it did not support classpath isolation. This has subsequently been addressed. I also thought it did not support project isolation, but that was just a misunderstanding due to the way the documentation was worded. nmcp requires one to do a bit more wiring, but that itself is not a bad thing, because for some projects that flexibility is what one needs. nempi OTOH does a bunch of wiring specifically for the straight-forward use cases. Under the hood both plugins have a lot in common. They only major difference is that nmcp relies on a settings plugin for a multi-project layout, whereas nempi uses only a project plugin with some additional config in the root project.
b
OK, thank you very much for the feedback @ysb33r!