Java Magazine, Jan/Feb 2017

ORACLE COM JAVAMAGAZINE JANUARY FEBRUARY 2017 27 tools Plugin Architecture No matter how extensive the build tool is it will never be able to address all the potential scenarios that developers encounter every day so it also needs to be expandable This is traditionally achieved by exposing a plugin architecture that developers can use to extend the tool and have it perform tasks it wasnt originally designed for A build tools usefulness is directly correlated to the health and size of its plugin ecosystem Interestingly while OSGi is a respectable and wellspecified architecture for plugin APIs I dont know of any build tool that uses it Instead build tools tend to invent their own plugin architecture which is unfortunate This topic would require an entire book chapter of its own so Ill just mention that there are basically two approaches to plugin architecture The first one is to give plugins full access to the internal structure of your tool which is the approach adopted by Gradle driven and facilitated by Gradles Groovy foundation In contrast the Eclipse and IntelliJ IDEA development environments and Kobalt expose documented endpoints that plugins can connect to and use in order to observe and modify values in an environment that the build tool completely controls I prefer this approach because its statically verifiable and much easier to document and maintain Package Management On top of being a very versatile and innovative build system Maven introduced what will most likely be a legacy that will far outlast it the repository Im pretty sure that even if Maven becomes outdated and no longer used well still be referencing and downloading packages from the various Maven repositories that are available today Given the popularity of these repositories a modern build tool should do the following Transparently support the automatic downloading of dependencies from these repositories Maven Gradle and Kobalt all do this Ant requires an additional tool Make it as easy as possible to make my projects available on these repositories Maven and Gradle require plugins and quite a bit of boilerplate in your build file Kobalt natively supports such uploads Auto Completion in Your IDE Developers spend several hours every day in their IDE so it stands to reason that they would expect all the facilities offered by their IDE to be available when they edit a build file Build tools have been moderately successful at this frequently offering partial syntactical support Interestingly Maven with its POM file has always been very well supported in IDEs because of its reliance on an XML format thats fully described in an XML schema The file is verbose but auto completion is readily available and reliable and Mavens schema is a very good example of how to define a proper XML file with very strict rules for example no attributes are ever used so theres never any hesitation about how to enter the data The more modern Gradle has been less successful in that area because of its reliance on Groovy and the fact that this language is dynamically typed Kobalts reliance on Kotlin for its build file enables auto completion to work in IntelliJ IDEA without requiring any special eforts Obviously the upcoming Kotlin based Gradle will enable similar levels of autocompletion as well These days nobody has time to go to a website download a package and manually install it Build tools should be no exception and they should self update