<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Gradle on Maveniverse</title><link>https://maveniverse.eu/tags/gradle/</link><description>Recent content in Gradle on Maveniverse</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 07 May 2026 13:07:11 +0200</lastBuildDate><atom:link href="https://maveniverse.eu/tags/gradle/index.xml" rel="self" type="application/rss+xml"/><item><title>Nisse got Gradle plugin!</title><link>https://maveniverse.eu/blog/2026/05/07/nisse-got-gradle-plugin/</link><pubDate>Thu, 07 May 2026 11:01:53 +0100</pubDate><guid>https://maveniverse.eu/blog/2026/05/07/nisse-got-gradle-plugin/</guid><description>&lt;p&gt;Reusable (minimal-dependency) &amp;ldquo;core&amp;rdquo;, and thin (no logic, just config) Mojos around, is how things should be done.
This is how Nisse was done as well among others, and is now the first Maveniverse project, that receives
&amp;ldquo;equally capable&amp;rdquo; Gradle plugin, next to existing Maven one.&lt;/p&gt;
&lt;p&gt;Check out the project: &lt;a href="https://github.com/maveniverse/nisse"&gt;https://github.com/maveniverse/nisse&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;But, is also the first project, that uses new Maveniverse ToolRunner to integrate Gradle build into Maven build.
Why not Gradle Wrapper and exec plugin? Because, ToolRunner not only executes the tool (Gradle in this case), but
also is capable to detect it, and provision it. And unlike with Gradle Wrapper, provisioning happens via Maven/MIMA
configured HTTP client, hence all the transport config, like proxies and authentication and all are applied
&lt;strong&gt;from Maven&lt;/strong&gt; configuration. &lt;strong&gt;Maven drives the process&lt;/strong&gt;, from beginning to end
(well, not &amp;ndash; yet &amp;ndash; the Gradle build process itself, but what if&amp;hellip;).&lt;/p&gt;</description></item></channel></rss>