Over a million developers have joined DZone.

Gradle Goodness: Custom Plugin Repositories With Plugins DSL

Learn more about hosting your own plugin repo on a company intranet.

· Java Zone

Microservices! They are everywhere, or at least, the term is. When should you use a microservice architecture? What factors should be considered when making that decision? Do the benefits outweigh the costs? Why is everyone so excited about them, anyway?  Brought to you in partnership with IBM.

To apply a plugin in our Gradle build script, we can use the plugins DSL. The plugins DSL is very concise and allows Gradle to be more efficient and more in control when loading the plugin. Normally the plugin we define is fetched from the Gradle plugin portal. If we have our own repository, for example on the intranet of our company, we have to define that extra repository with a pluginRepositories configuration block in the settings.gradle file of our project.

In the following sample, we have a plugin mrhaki.gradle.version-file that is stored in the company intranet repository with the URL http://intranet/artifactory/libs-release/.

// File: settings.gradle
// As the first statement of the settings.gradle file
// we can define pluginRepositories:
pluginRepositories {
    maven { url 'http://intranet/artifactory/libs-release/' }
    gradlePluginPortal() // Include public Gradle plugin portal

In our build file we use the plugins DSL to apply the mrhaki.gradle.version-file plugin:

// File: build.gradle
plugins {
    id 'mrhaki.gradle.version-file' version '1.2.2'

There is a restriction when we use this approach. The plugin must be deployed to our intranet repository with plugin marker artifacts. Gradle needs these to resolve the value for id to the correct plugin. A plugin marker artifact is a deployment following a specific naming convention with a dependency on the actual plugin code. If we write our own plugin we best can use the java-gradle-plugin (Java Gradle Plugin Development Plugin), which automatically adds the plugin marker artifacts when we publish our plugin to the intranet repository.

We could also have used the buildscript configuration block in our build.gradle file to define a custom repository for our plugin. Inside the buildscript configuration we use the repositories block to add our intranet repository. But than we cannot use the plugins DSL, but have to use the apply plugin: syntax.

Written with Gradle 3.1.

Discover how the Watson team is further developing SDKs in Java, Node.js, Python, iOS, and Android to access these services and make programming easy. Brought to you in partnership with IBM.

java ,dsl ,gradle ,repositories

Published at DZone with permission of Hubert Klein Ikkink, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}