Jenkins : Split plugin from core

Created by Unknown User (batmat), last modified by Unknown User (jglick) on Nov 15, 2017

Presentation

See this walk-through by Unknown User (jglick) in Sep 2017.

Goal of this doc

Jenkins has a plugin architecture. For historical reasons, some features were developed inside the Jenkins codebase itself (i.e. not as plugins).

To keep that core codebase more manageable, there is an ongoing effort to extract some of the existing features into dedicated plugins.

General process to extract classes

  • Locate everything that should be moved.
    • Do not forget to look in core/src/main/resources/ for associated resources.
      • (Messages.properties shared with other classes in the same package can be a headache: you need to create a new Messages in a novel package.)
    • And look for relevant functional tests in test/src/test/.
    • And icons.
    • And double-check that you have really found everything relevant:
      • git ls-files | grep -F SOMETHING for filenames and
      • git ls-files | xargs grep -l SOMETHING for contents.
  • Try temporarily deleting all the classes you propose to split, and do a clean build to verify that there are not unwanted usages from elsewhere in core. If there are, you have some refactoring ahead of you, and this is where it gets hairy.
  • Split the code into a new repository with history intact. git-filter-branch can work, though it is not easy to use; IIRC KK had some script expressly for this purpose but I can never find it when I need it. If possible, make sure translated commits mention the original commit hash.
  • Do a 1.0 release of the new plugin, with the baseline set to the last weekly prior to your split. Ideally you would actually use the -SNAPSHOT version from the current core but Maven release rules will forbid this.
  • Create a core patch to:
    • delete the split files
    • bundle in `war/pom.xml`
    • list in `ClassicPluginStrategy.DETACHED_LIST`
  • After a new weekly is produced using the above changes, update the baseline in the new plugin to that and cut a 1.1 (or 1.0.1). This ensures it is only offered to users who do not still have that functionality in core. Assuming the UC is configured properly.
  • Pat yourself on the back: Jenkins sources are a little more manageable than they were yesterday.