Patch process outline

1. If patch plugin is disabled (config: <disabled>false</disabled>) then disable all patch steps
2. Check for patch artifact given current POM info (version, etc.)
3. If patch artifact was resolved, unpack it and set a flag for existing patch artifact being found. Set the patch source dir to the unpack location.
4. If patch artifact was not resolved, set the patch source dir to the configured source directory (src/patches by default).
5. Apply all patch files in the patch-source directory. Require an ordering list, and allow specification of strict-follow, to fail the build if all specified patches are not present.
6. If the patch artifact was not resolved, this is a new project. Create the patch-archive artifact, and attach it to the project artifact for installation/deployment.
7. When installing the project artifact, go back and delete the patch artifact from the local repository, so we can detect when the patch artifact is actually deployed for the first time...we'll need this to keep from installing the patch artifact locally, then never deploying it again (since it'll resolve from then on).

Lifecycle Bindings

The resolve-pathces mojo is bound to the initialize lifecycle phase, to enable retrieval of patches before the main build process starts.

The apply-directory mojo is bound to the process-sources lifecycle phase, to modify the source code before it is compiled. It's important to note that the apply-directory mojo's placement in the lifecycle must be tightly controlled relative to other mojos in the process-sources phase, especially in the case of Make-based builds, since these builds commonly require a configuration step to execute prior to code compilation.