Feature/ims java dbb task#121
Open
davidjwriter wants to merge 7 commits into
Open
Conversation
- Add ImsJavaBuilder.groovy: custom DBB task that runs mvn clean install via configurable mavenPath, auto-detects the output JAR, registers it in the build map with deployType=IMS-JAR, and adds it to BUILD_LIST so the Package task includes it in the tar - Register ImsJavaBuilder in dbb-build.yaml (full/impact/pipeline lifecycles) with IMS-JAR BINARY copyMode mapping - Add ImsJavaBuilder task config to dbb-app.yaml (mavenPath, configSources) replacing the hardcoded maven invocation in the shell - Remove hardcoded mvn build block from task-dbb-build.sh (lines 156-161) - Add IMS-JAR type entry to types_pattern_mapping.yml deploying to sandbox_path/jars — same path the shell script was writing to - Add Deploy IMS JAR activity to deployment-method.yml - Wire sandbox_path from config.yaml through task-wazi-deploy.sh into Wazi Deploy via -e sandbox_path flag, matching the zos_connect_root pattern; add sandbox_path variable to Development.yml
git remote get-url origin returns git@github-public:IBM/Bank-of-Z.git when using a local /etc/hosts alias. The sed conversion to HTTPS produced https://github-public/... which z/OS cannot resolve. Add a second sed pass to rewrite any https://github-*/ variant back to https://github.com/ before passing the URL to the remote git clone command.
…te clone" This reverts commit 5fbd030.
Two bugs from the initial implementation: 1. [mvnCmd].execute() treated the entire command string as the executable name. Split into a proper args list so the JVM spawns mvn with the correct argv. 2. outputDirectory (DBB logs dir) was passed as -DoutputDir. Add explicit jarOutputDir config variable pointing to the sandbox jars dir, matching the dfsjvmpr.props classpath. Also add failOnError: true to VanillaFrontend, ServerXmlPackager, and ImsJavaBuilder task definitions so a Groovy task failure propagates as a build failure instead of being silently ignored.
…end WAR The JAR must go into outputDirectory (the DBB package staging area) so the Package task picks it up into the tar, then Wazi Deploy extracts and places it at sandbox/jars. This matches exactly how: - VanillaFrontend writes api.war into outputDirectory - zOSConnect writes api.war into outputDirectory via buildOpenAPIv3() Remove the jarOutputDir config variable and hardcoded sandbox path that was incorrectly bypassing the package.
failOnError is not a valid DBB task schema property. Groovy tasks already signal failure by returning 8, which sets STATUS=ERROR in the build context. Subsequent tasks can check STATUS via condition.
…n wiping shared artifacts
pom.xml sets <directory>${outputDir}</directory> meaning Maven's build
directory (and mvn clean target) IS outputDirectory. Running mvn clean
deleted the WAR and server.xml that VanillaFrontend and ServerXmlPackager
had already written there, causing Package to fail.
Fix: build into a private ims-java-build-temp subdir, then copy only
the final JAR into outputDirectory. Mirrors VanillaFrontend's pattern
of building in vanilla-war-temp then placing the WAR in outputDirectory.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This pull request integrates the IMS Java build process into the DBB (Dependency Based Build) pipeline, replacing the previous ad-hoc shell script approach. A new Groovy task (
ImsJavaBuilder) is introduced to compile the IMS Java JMP project via Maven, package the resulting JAR with a dedicatedIMS-JARdeploy type, and register it in the DBB build map for deployment via Wazi Deploy. The deployment configuration is updated accordingly to handle the new artifact type and route it to the correct USS classpath directory.Files Changed
📄
.setup/build/dbb-build.yamlRegisters
ImsJavaBuilderas a build lifecycle step across all three lifecycle definitions (pipeline, impact, and full build). Also adds a newIMS-JARdeploy type withBINARYcopy mode to the packaging task configuration, and defines the newImsJavaBuildertask pointing to its Groovy script.📄
.setup/build/groovy/ImsJavaBuilder.groovyNew Groovy DBB task script that handles the full IMS Java build and packaging lifecycle. It performs change detection for pipeline/impact builds (skipping the build if no IMS Java source files changed), runs
mvn clean installin a temporary directory to avoid clobbering existing build artifacts, copies the produced JAR into the DBB output directory, and registers it in the DBB build map withdeployType=IMS-JAR. The Maven executable path and source directory are configurable via task variables.📄
.setup/deploy/Development.ymlAdds a new
sandbox_pathvariable, defaulting to/usr/local/sandboxes/bank-of-z, which is used by the types pattern mapping to determine the deployment destination directory for the IMS JAR artifact.📄
.setup/deploy/deployment-method.ymlAdds a new Wazi Deploy activity definition —
Deploy IMS JAR— that handles copyingIMS-JARtyped artifacts to the USS classpath directory using theUSS_COPYstep.📄
.setup/deploy/types_pattern_mapping.ymlAdds a new type mapping entry for the
IMS-JARdeploy type. Matched artifacts are deployed as binary files to{{ sandbox_path }}/jarson USS, with a backup destination at{{ sandbox_path }}/jars/backand file mode0755.📄
.setup/tasks/task-dbb-build.shRemoves the previously hardcoded Maven build block for IMS Java (
mvn clean install), as this responsibility has been moved into the newImsJavaBuilderDBB Groovy task.📄
.setup/tasks/task-wazi-deploy.shExports the
SANDBOX_PATHenvironment variable (sourced from thesandbox.pathconfiguration section) and passes it as an extra variable (-e sandbox_path=$SANDBOX_PATH) to thewazideploy-deploycommand so that deployment targets the correct USS directory.📄
dbb-app.yamlAdds the
ImsJavaBuildertask configuration block to the application definition, specifying the Maven executable path (mavenPath) and the relative path to the IMS Java Maven project directory (configSources).