Mavenization Process

Development Process

1. Identify a project not yet mavenized on the status list
2. Mavenize the project
3. Add or update README.md and ensure that it contains the current build instructions. You can use this as a template https://github.com/pentaho/maven-project-archetypes/blob/master/pentaho-ce-jar-archetype/src/main/resources/archetype-resources/README.md
4. Add the common .gitignore file located here: https://github.com/pentaho/maven-project-archetypes/blob/master/pentaho-ce-jar-archetype/src/main/resources/archetype-resources/.gitignore
5. Add licensing information as detailed here.
6. Remove any other artifacts created and used by IDE's, like Eclipse's .project files or IntelliJ's .iml files. The project configuration should be purely driven by the POM when imported as a maven project.
7. Enter an ENGOPS Jira case titled "Mavenizing ". Add detailed description in the ticket as necessary and then copy in the work details from the Build Engineering Process section below.
8. Link the ENGOPS Jira case to the BACKLOG case
9. Inform the [email protected] that the new ticket is ready for work–this will accelerate the triage and prioritization process. Additional notification via direct messaging a good thing, but it does not replace the buildteam notification requirement.
10. Submit a Pull Request and perform standard reviews
11. Work with Build Engineer to schedule when the Pull Request should be committed
12. Once committed, update the ENGOPS case so any affected Jenkins jobs can be switched to use Maven
13. When notified by build team, rebase to ensure branch is up to date before it is merged
14. Test the resulting build artifacts (and downstream projects), to ensure success

Build Engineering Process

Work details for the ENGOPS ticket created by development

1. Clone, build, and analyze the mavenized project for best practices conformance.
2. Create a new job for the project from the Suite Build Job Maven Template. Use the same Jenkins job name for the project with "-maven" suffix.
3. Create a custom build resources branches named -maven-qat and -maven-snapshot.Then build QAT and SNAPSHOT (unit-tested) versions of the project from a build flow job.both QAT and SNAPSHOT (tested) builds Remember that we cannot drive a release machine build purely with the job parameters: a build flow with all required parameters and environment settings is required to control Jenkins build node and dependency cache isolation.
4. Once the mavenization build has been tested in release and snapshot mode, let development know that we are ready for them to merge.
5. Development maven merge notification requires build to finalize these items for QAT build integration:
6. Identify ALL Jenkins build jobs, build order, and output artifacts generated by the mavenized project. Don't forget that some projects are cloned and different parts are built in different slots in the dependency-ordered suite build stack.
7. Rename the existing ant project build with "-ant" suffix, rename the new "-maven" build by removing the "-maven" suffix.
8. Change any custom build targets in the build-flow.csv if necessary (usually this will mean deletiong of any custom BUILD_TARGET or PUBLISH_TARGET parameters because maven builds should not normally require them.
9. Remove any existing (same branch!) SNAPSHOT artifacts in the Nexus repository for this project.
10. Delete (or request Administrator deletion) of the Sonar history for the project's branch quality reporting.
11. Run a final test build from the build flow for the new mavenized job.