Plugin Development

Jenkins is designed from the ground up to be extensible. Most functionality in Jenkins—from source code management and build tools to user interface enhancements and notification systems—is implemented as plugins.

How Plugins Work

Jenkins defines numerous extension points (interfaces or abstract classes) that model aspects of its behavior. Plugins implement these extension points and mark their implementations with @Extension. Plugins are packaged as .hpi/.jpi archives (see Build Process). At compile time, an annotation processor (SezPoz) records @Extension classes in an index inside the plugin (see Annotation Processing). During startup, Jenkins reads this index to find and instantiate the extensions, rather than scanning classes reflectively.

Class Loading

Jenkins loads each enabled plugin in its own class loader, which delegates to Jenkins core and to the class loaders of the plugins it depends on. A plugin can therefore use classes from Jenkins core and from its dependencies, including third-party libraries those dependencies bundle. See Dependencies and Class Loading for details.

Seamless Integration

Plugins participate across all major Jenkins subsystems just like built-in classes:

  • Persistence: Plugin data is persisted using XStream as XML files in JENKINS_HOME. Plugin developers must preserve backward compatibility explicitly as their classes evolve; see Persistent Objects.

  • Web Views: Plugins provide UI views using Jelly or Groovy that render seamlessly within the Jenkins UI layout.

  • HTTP Routing: Plugins can bind methods and objects to URLs via Stapler to expose REST endpoints or web pages.

  • Static Assets: Plugins can serve static resources such as icons, images, JavaScript, and CSS.

Getting Started

To learn more about developing Jenkins plugins, explore the following topics:

Sections

How-To Guides

References