This post is about „How to build your own pluginnable application“. As a playground example I want to create a core application that is easily extendable by just putting a plugin-jar into a plugins folder.
Just a small example to show how to use sbt instead of classical maven to build a java program and deploy it to Nexus repo manager.
It may happen, that you wish to specify a custom location of your logfile when running your Java app. Within this post I use an example cli application that is written in Groovy and build with Gradle. By passing „–logfile=mylogfile.log“ it will write all logs to the specified location, while it is using the Slf4j-annotation described in one of my previous posts.
When playing around with the concepts of Continuous Integration/Delivery/Deployment I struggled over Gradle builds and how to integrate them in these concepts. Gradle is getting more and more important in build tool landscape and so I created a template or archetype about how to use it.
I choose a scenario that I saw already implemented with Maven and other tools:
- pushing a VCS change to central VCS
- tagging that change to a specific id and pushing it back to central VCS
- executing the build with unit tests
- executing the sonar analysis
- executing the artifactory upload
This chain gives you the ability of continuously having every change explicitely tagged, unit-tested, analyzed and uploaded to your artifact repository, ready for deployment. In short, this is (from my point of view) the spirit of Continuous Delivery.
Jenkins can be configured in many ways. When trying to find a suitable solution for deployment of plugins, we’ve been facing to the problem of using not (!) the latest and greatest plugin versions. This can be necessary when using the jobdsl plugin without having the resources to update our own dsl library when there comes up a non-downstream-compatible version of the jobdsl plugin. But this is only one example, there are more 🙂