Skip to content
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

Refactoring loading build properties #402

Merged

Conversation

dennis-behm
Copy link
Member

zAppBuild is leveraging 3 properties buildPropFiles, applicationDefaultPropFiles and applicationPropFiles, that each define a list of additional properties to load to configure zAppBuild.

The PR is proposing the following changes:

  • (Attention!) Replacing the applicationConfRootDirproperty with a configuration parameter to define where zAppBuild is locating the application-conf folder which includes the application.properties file.
  • Providing a new load method, that will exit the build, when a referenced property file is not found, instead of throwing a FileNotFound exception.
  • Make an application specific application-conf directory optional, when zAppBuild is configured via the central configuration parameters buildPropFiles and applicationDefaultPropFiles properties. (See HOWTO recipe).

@dennis-behm dennis-behm requested a review from M-DLB August 18, 2023 08:52
Copy link
Member

@M-DLB M-DLB left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @dennis-behm !
There are some typos too, in the HOWTOS.md mainly, if you can have a look, please.

@@ -1,12 +1,12 @@
# Application Configuration
This folder contains application specific configuration properties used by the zAppBuild Groovy build and utility scripts. It is intended to be copied as a high level folder in the application repository or main application repository if the application source files are distributed across multiple repositories. Once copied to the application repository, users should review the default property files and modify any values as needed.

At the beginning of the build, the `application-conf/application.properties` file will automatically be loaded into the [DBB BuildProperties class](https://www.ibm.com/support/knowledgecenter/SS6T76_1.0.4/scriptorg.html#build-properties-class). Use the `applicationPropFiles` property (see table below) to load additional application property files.
At the beginning of the build, the `application-conf/application.properties` file will automatically be loaded based on the definition of `applicationConfDir` [property](../../build-conf/build.properties) into the [DBB BuildProperties class](https://www.ibm.com/docs/en/dbb/2.0?topic=apis-build-properties#build-properties-class). Use the `applicationPropFiles` property (see table below) to load additional application property files.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can say that it's "by default, zAppBuild is configured to look at application-conf/application.properties but this can be changed. Something like:

At the beginning of the build, the application.properties file will automatically be searched and loaded if it exists into the DBB BuildProperties class. The application.properties file is by default searched in the application-conf folder of the application, but this can be modified through the applicationConfDir property.

docs/HOWTOS.md Outdated
zAppBuild provides 3 properties `buildPropFiles`, `applicationDefaultPropFiles` and the `applicationPropFiles` that each reference a list of properties files, which contain important configuration parameters to configure the build process. The referenced properties files are loaded in the below order of precedence:

* `buildPropFiles` managed in [build-conf/build.properties](../build-conf/build.properties) references properties files in the [build-conf](../build-conf/) directory for core zAppBuild settings for the language scripts such as system datasets, naming conventions of build datasets, dataset characteristics and various core properties of the build framework as well, like the reporting features.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we say that these properties are "enterprise-level" properties for the build framework (i.e. low-level properties)? Could you add something like that, please?

docs/HOWTOS.md Outdated

* `buildPropFiles` managed in [build-conf/build.properties](../build-conf/build.properties) references properties files in the [build-conf](../build-conf/) directory for core zAppBuild settings for the language scripts such as system datasets, naming conventions of build datasets, dataset characteristics and various core properties of the build framework as well, like the reporting features.
* The property `applicationDefaultPropFiles` is managed in [build-conf/build.properties](../build-conf/build.properties) as well and allows the user to define default application (and also language script specific related) properties, that are centrally managed.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To make it a bit clearer, could you say that these properties are "enterprise-level" properties shared across all applications, and provide examples (I don't know, maybe default compile options?) ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added 97ff to explain the difference between enterprise-level/central and local

docs/HOWTOS.md Outdated
* `buildPropFiles` managed in [build-conf/build.properties](../build-conf/build.properties) references properties files in the [build-conf](../build-conf/) directory for core zAppBuild settings for the language scripts such as system datasets, naming conventions of build datasets, dataset characteristics and various core properties of the build framework as well, like the reporting features.
* The property `applicationDefaultPropFiles` is managed in [build-conf/build.properties](../build-conf/build.properties) as well and allows the user to define default application (and also language script specific related) properties, that are centrally managed.
* `applicationPropFiles` is referencing properties files providing application specific settings. This property is managed in the applications' `application-conf/application.properties` file which is by default located in the applications' [application-conf](../samples/application-conf/) folder. These settings define compiler and link options, deploy types, script mappings and search path configurations for the DBB dependency and impact analysis. A sample is provided in [application-conf](../samples/application-conf/). The default location for zAppBuild to locate the `application.properties` file within the `application-conf` directory is defined via the `applicationConfDir` setting that is managed in [build-conf/build.properties](../build-conf/build.properties). The default mandates am `application-conf` folder including the `application.properties` file to be present in the applications' git repository.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment - Can we say these are "application-level" properties and that they override the default properties defined through applicationDefaultPropFiles?

@dennis-behm dennis-behm linked an issue Aug 31, 2023 that may be closed by this pull request
Copy link
Member

@M-DLB M-DLB left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All good, thank you @dennis-behm

@M-DLB M-DLB merged commit b207282 into IBM:develop Sep 1, 2023
ijmitch pushed a commit to ijmitch/dbb-zappbuild that referenced this pull request Sep 12, 2023
Reorganization of the application-level properties into centrally-managed properties files

Signed-off-by: Dennis Behm <[email protected]>
Co-authored-by: Mathieu Dalbin <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Refactor loading application-conf directory
2 participants