Best practice is to use the JIRA issue title in both the pull request title and in the first line of the commit message.
 - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
 - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will
       be performed on your pull request automatically.
 - [ ] You have run the [Core IT][core-its] successfully.

+ [Contributor License Agreement][cla]
+ [General GitHub documentation](https://help.github.com/)
+ [GitHub pull request documentation](https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork)
+ [Apache Maven Twitter Account](https://twitter.com/ASFMavenProject)
+ #Maven IRC channel on freenode.org

    a debug message.

  * If the wagon is bound to "file://" then:

    Retrieve the file or base-url file to be "downloaded".

    * If the file (or more usefully, the base-url file) exists, proceed.

    * If the file (or base-url file) doesn't exist, assume that this location
      is part of a file-share. Ignore the request and print a debug message
      as above.

  .
  .
  .
</plugins>

We need this form so that the model builder can make the first pass at merging. Full merging cannot be done because we don't know what the version of the plugin is yet that the user has requested. For plugins in the default lifecycle they are typically defined in the plugin management section of the parent POM. When the merging is complete we are going to have something that looks like the following:

<plugins>
  <plugin>

When a plugin has a complete and valid configuration, the plugin would be looked up in the Plexus container and be ready to perform any operations requested of it.

h3. Execution of the plugin