In the organization i have been working for , i have seen many gradle build scripts , which do the “same” over and over again, with only slight variants.
Example: a build script, which builds Java code, with a couple of dependencies, where the versions are managed by the Nebula Dependency management Plugin, copies all resources into a target directory structure with some property expansion and filters, generates a Zip File from that directory, builds from there a Rpm with the nebula plugin and in the end deploys jar, zip and rpm to a Artefactory repository using the the maven-publish plugin in combination with the Artefactory plugin.
So the scripts do a lot of not very complex but useful things, driven by useful plugins.
But one can also easily see how for an enterprise there is lot’s of standardization potential and in terms of usage scenarios not much variability. Some standardization examples: repository naming, respository user & password, directory layout for the RPM, Rpm User and User groups, service naming etc. Examples for variability: systemd unit name, installation directory naming, package name etc
The strategy up to now has been copy & paste, which we are now realizing simply doesn’t scale.
So we are looking for ways to reuse build logic in the purest sense of the word.
Since we never want to reinvent the wheel, we are studying the Gradle documentation in this regard:
Where the apply from resp Script Plugin feature seems quite straight forward, see https://docs.gradle.org/current/userguide/plugins.html#sec:script_plugins and understable, also the restrictions of this approach (caching, versioning etc).
I am slightly disappointed with the recommendations with regard to binary Plugin recommendation:
I find the gradle documentation about organizing and reusing build logic highly theoretical, see https://guides.gradle.org/designing-gradle-plugins/#reusable_logic_should_be_written_as_binary_plugin and actually beside the point: because it is more about providing new functionally and not so much about (re) using existing functionality, which in the end boils down to reusing existing plugins
I do not see in the examples https://github.com/bmuschko/gradle-docker-plugin#provided-plugins and https://github.com/bmuschko/gradle-docker-plugin#provided-plugins not much of reusing build logic, but providing new functionality, which can be reused. Ok fair enough also important, but in the Build world , i find the reuse of existing functionality with slight variants much more important. Also googleing i don’t find much : https://objectpartners.com/2014/04/24/reuse-your-gradle-logic-across-the-enterprise/
Whereas i completely get writing a plugin to do something new, easy, i don’t see how i can apply existing plugin, configure and execute their tasks with any justifiable effort.
I don’t see that any real world scenario of factoring out repeated build logic also with the desire to enforce useful standards and which differs essentially only in some parameters, can be achieved with a binary custom plugin, which naturally in the above outlined scenario depends the ‘java’ , ‘maven-publish’ , ‘com.jfrog.artifactory’ , ‘nebula.ospackage’ and currently also on the ‘nebula.dependency-recommender’.
Or: apply from and apply plugin are really two very different beasts.
Am i wrong? I would be very happy to be proven wrong. Are there real world examples for above scenario?
Or should we stick with copy & paste
Best thanks, any feedback is greatly welcomed