Traditional Jenkins Job
s are defined in a fairly deep type hierarchy:
FreestyleProject
→ Project
→ AbstractProject
→ Job
→ AbstractItem
→ Item
.
(As well as paired Run
types: FreestyleBuild
, etc.)
In older versions of Jenkins, much of the interesting implementation was in AbstractProject
(or AbstractBuild
),
which was packed full of assorted features not present in Job
(or Run
).
Some of these features were also needed by Pipeline, like having a programmatic way to start a build (optionally with parameters),
or lazy-load build records, or integrate with SCM triggers.
Others were not applicable to Pipeline, like declaring a single SCM and a single workspace per build,
or being tied to a specific label, or running a linear sequence of build steps within the scope of a single Java method call,
or having a simple list of build steps and wrappers whose configuration is guaranteed to remain the same from build to build.
WorkflowJob
directly extends Job
since it cannot act like an AbstractProject
.
Therefore some refactoring was needed, to make the relevant features available to other Job
types without code or API duplication.
Rather than introduce yet another level into the type hierarchy (and freezing for all time the decision about which
features are more “generic” than others), mixins were introduced.
Each encapsulates a set of related functionality originally tied to AbstractProject
but now also usable from
WorkflowJob
(and potentially other future Job
types).
-
ParameterizedJobMixIn
allows a job to be scheduled to the queue (the older BuildableItem
was inadequate),
taking care also of build parameters and the REST build trigger.
-
SCMTriggerItem
integrates with SCMTrigger
, including a definition of which SCM or SCMs a job is using,
and how it should perform polling. It also allows various plugins to interoperate with the Multiple SCMs plugin
without needing an explicit dependency. Supersedes and deprecates SCMedItem
.
-
LazyBuildMixIn
handles the plumbing of lazy-loading build records (a system introduced in Jenkins 1.485
).
For Pipeline compatibility, plugins formerly referring to AbstractProject
/AbstractBuild
will generally
need to start dealing with Job
/Run
but may also need to refer to ParameterizedJobMixIn
and/or SCMTriggerItem
.
(LazyBuildMixIn
is rarely needed from outside code, as the methods defined in Job
/Run
suffice for typical purposes.)
Future improvements to Pipeline may well require yet more implementation code to be extracted from AbstractProject
/AbstractBuild
.
The main constraint is the need to retain binary compatibility.