Plugin Library Provider
We have created a sample repository you can use to get started when packaging your libraries as a plugin.
Development Workflow
When developing a library providing plugin, it can shorten the feedback loop during development to configure an SCM Library that is configured to load from the plugin’s source code repository with a base directory of src/main/resources/libraries.
Once updates have been validated, the libraries can then be built into a plugin for distribution.
Why package libraries this way?
It’s a lot less work to configure a source code repository and configure it as a library source. So why would someone want to spend the time packaging their libraries as a Jenkins Plugin?
1. Plugin Dependency Management
Steps contributed by libraries often rely on particular Jenkins plugins in their implementation. Packing libraries as a Jenkins Plugin ensures that all other plugin dependencies (and their versions) are satisfied when installing the library providing plugin.
2. Initialization Performance
It slows down library loading to reach out to a remote source code repository to retrieve libraries. When packaged as a plugin, JTE no longer needs to fetch libraries from the remote repository.
3. Ensuring a specific version of JTE
It can be helpful to ensure that specific version of the Templating Engine Plugin is installed if the interface between JTE and libraries changes.
4. Library Source Versioning
One specific use-case for the Templating Engine Plugin is for DevOps engineers supporting multiple pipelines simultaneously. In these situations, the libraries provided are likely shared across the teams as well. Over time, libraries can be changed in a way that breaks backwards compatibility. Packaging libraries as a plugin allows you to version your set of libraries as an artifact where teams can upgrade when it makes the most operational sense.