The Gradle POM

Gradle is an extensible and very flexible build tool capable of building projects that target many platforms, not just Java. In the Java space it’s often compared to Apache Maven; one of the often cited complains against Gradle is that it’s “too complicated” or rather “too flexible” when compared to Apache Maven. It appears a large percentage of Maven users do love having a fixed structure that restricts the amount of havoc a junior developer may bring to the project if he or she desires to play with the build file. However this fixed structure also restricts power users from tweaking the build when the need arises. Despite this, the general perception is that Apache Maven’s structure is good enough while Gradle provides no fixed structure, that is, every Gradle build is a custom build and we’re back to the days of Apache Ant where copying build definitions from one file to another was the norm, as well as praying the build would do what we expected.

Or are we really? What if there was a way to introduce a common structure on top of a project while retaining flexibility when needed? What if we can have this structure follow our own conventions instead of those dictated by a third party? This is what the kordamp-gradle-plugins project aims to deliver. As the guide found in the previous link explains, you may apply each plugin individually or apply the org.kordamp.gradle.project plugin which aggregates lots of behavior you’d expect coming from Maven. Here are some examples of these plugins in use

As you may appreciate, build files tend to be smaller and follow the same structure. All these projects enjoy the following benefits:

  • Centralized point of configuration via a common DSL. This DSL is available for Groovy and Kotlin build files.
  • Generate source and javadoc JARs. In the case of a multi-project build also generate aggregate Javadocs.
  • All test task produce a JaCoCo report. In the case of a multi-project build also generate aggregate JaCoCo reports.
  • All JARs have their manifest enriched with additional entries such as build date/time/revision and more.
  • The main artifact JAR contains Maven compatible pom.xml and pom.properties usually placed under META-INF/maven. This makes it easier for published artifacts to be consumed by tools that expect these files.
  • Prettified source reports made via Java2HTML and Maven’s JXR.
  • Publication to Bintray is enabled by default, with automatic syncing to Maven Central configured as well.
  • License and file header checks are setup automatically.

All of these features can be turned off if they are not needed. It’s worth noting that some of these plugins rely on external plugins, in which case their original behavior and extension points remain available to you. Such is the case of the org.kordamp.gradle.license plugin which relies on the com.github.hierynomus.license; similarly the org.kordamp.gradle.build-info, org.kordamp.gradle.bintray, org.kordamp.gradle.kotlindoc, org.kordamp.gradle.source-html, and org.kordamp.gradle.guide plugins depends on external plugins that you may further configure in any way you deem necessary.

The current release (0.8.0) specifically targets projects that are released as Open Source and would use Bintray as the main repository for publications. The next releases will include the ability to

  • Sign artifacts using the core signing plugin.
  • Configure publications to Maven compatible repositories (including release and snapshots).
  • Support android projects. Currently only Java, Groovy, and Kotlin projects are supported.

As always, feedback is welcome. Please file a ticket at https://github.com/aalmiray/kordamp-gradle-plugins/issues if you find something is missing or not working correctly.

Trackbacks/Pingbacks

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

ˆ Back To Top