-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for zCEE OpenAPI 3.0 processing #375
Conversation
Signed-off-by: Mathieu <mathieu.dalbin@fr.ibm.com>
Signed-off-by: Mathieu <mathieu.dalbin@fr.ibm.com>
Signed-off-by: Mathieu <mathieu.dalbin@fr.ibm.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@M-DLB , I have added a couple of comments and wished in the below review.
build-conf/zCEE3.properties
Outdated
|
||
# | ||
# When set to true, always rebuild the WAR file, even if one is found in the build folder of the z/OS Connect project folder. | ||
# When set to false, will pick the existing WAR file if found or will build it if no WAR file is found |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A WAR file should not be under version control at all. I think it is safe to assume, that we always need to produce a new *war file ZCEE3 anyway.
My suggestion would be to drop this property, and we always build when the openapi specification has changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I completely agree, but it's the z/OS Connect Designer that creates the WAR file, and store it inside the Git repository (and there is nothing you can do to avoid it as far as I know).
I think we should still propose this option, but set it as optional, and set the default to true (as I did in this version).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make a comment about using .gitignore
to avoid storing the WAR there?
Sign-off-by: Mathieu <mathieu.dalbin@fr.ibm.com>
|
||
|
||
# | ||
# When set to true, always rebuild the WAR file, even if one is found in the build folder of the z/OS Connect project folder. | ||
# When set to false, will pick the existing WAR file if found or will build it if no WAR file is found | ||
# zCEE_alwaysRebuildWAR=true | ||
# When not specified, the default value is set to true | ||
#zcee3_alwaysRebuildWAR= |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@M-DLB Still believe, we should not have this property at all, because someone could just build it somewhere (locally), then inject the WAR into the repo and nobody knows what the input to this WAR was.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fine, and I tend to agree! Completely removed :)
Signed-off-by: M-DLB <mathieu.dalbin@fr.ibm.com>
build-conf/zCEE3.properties
Outdated
zcee3_shellEnvironment=bash | ||
|
||
# | ||
# Absolute path to gradle executable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add a comment, that this is gradle on z/OS UNIX System Services? The script does not support a "distributed" build.
languages/zCEE3.groovy
Outdated
|
||
File gradleExecutable = new File(gradlePath) | ||
if (!gradleExecutable.exists()) { | ||
def errorMsg = "gradle wasn't find at location $gradlePath." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we prefix the msg with *!
, please?
languages/zCEE3.groovy
Outdated
} | ||
String shellEnvironment = props.getFileProperty('zcee3_shellEnvironment', buildFile) | ||
|
||
command = [shellEnvironment, gradlePath, gradleBuildLocation] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the command is still executed, even if we did not find the gadlePath
?
Signed-off-by: Mathieu <mathieu.dalbin@fr.ibm.com>
Signed-off-by: Mathieu <mathieu.dalbin@fr.ibm.com>
Signed-off-by: Mathieu <mathieu.dalbin@fr.ibm.com>
Signed-off-by: M-DLB <mathieu.dalbin@fr.ibm.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @M-DLB some minor comments that are worth to consider
Signed-off-by: Mathieu Dalbin <mathieu.dalbin@fr.ibm.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the new language processing script!
* Added support for zCEE OpenAPI 3 Signed-off-by: Mathieu Dalbin <mathieu.dalbin@fr.ibm.com> Signed-off-by: Ian J Mitchell <ianj_mitchell@uk.ibm.com>
The zCEE3.groovy script provides support for z/OS Connect builds using gradle.
This zCEE3.groovy is aiming to support the OpenAPI 3.0 compatible API definitions (as created through the z/OS Connect Designer). The script uses the gradle configuration available in the OpenAPI definition to create a WAR file that contains the API's deployable artifacts.
Sample properties files are provided, in the
build-conf
configuration folder, for enterprise-wide properties, and inapplication-conf
folder for application-level overrides if necessary. File-level overrides can also be implemented infile.properties
.