Enhancement to create a build.properties override for the language files.

[rsjrny]

I am looking for an enhancement to supply an override for the location of the language files. I accomplished it in my copy of the dbb with the code below.

build.groovy line 302:

// load application.properties
    String appLangRootDir = props.applicationLangRootDir ?: props.workspace
    if (!appLangRootDir.endsWith('/'))
        appLangRootDir = "${appLangRootDir}/languages/${application}"
    if (opts.v) println "** Loading application Language Root Dir ${appLangRootDir}"

    String appLang = "${appLangRootDir}"
    if (opts.v) println "** appLang = ${appLang}"

build.properties approx Line 46:

#
# application language override - where the product language files are located (procgrps)
applicationLangRootDir=/u/prodpc2/scripts/dbbuild/

[dennis-behm]

@rsjrny Thanks for proposing this enhancement. Your proposed changes will definitely work.

However, I believe, because the languages scripts depend on several other parts of zAppBuild framework (like the different utilities), these components belong together as one unit / one configuration.

For example with the recent updates to zAppBuild for moving from the RepositoryClient to the MetadataStore packages or leveraging the new SearchPathDependency APIs, both parts are depending on each other and built one configuration.

What is the background for you to separate out the language scripts?

[rsjrny]

Thanks @dennis-behm ,

I want to split the language.groovy and properties away from the product repositories so the languages and properties are NOT updatable by users of the repository. I am supporting 15 products and am currently configured like:

my productN_folder is the application name from the args. If I had

dbb_configs_folder
   product1_folder
      application-conf
      build-conf
      languages

   product2_folder
      application-conf
      build-conf
      languages

   product3_folder
      application-conf
      build-conf
      languages

I have split zAppBuild and its pieces into a script directory. Then take the -conf and languages and put them into individual product directories. by adding the additional property for the languages I modified the code to add the property to the language line. It really is the same override as applicationConfRootDir= so I really only needed to update that code (/languages/) to use the existing override (duh)

What I am honestly trying to accomplish is this but I am still learning the code

I want to use the Assembler.groovy language but use a properties file based on the .ext of the file. so, if my extension is asm01 I changed the scriptmapping to */asm to use Assembler.groovy but I would like it to use asm01.properties (the .ext value)

I currently have copied Assembler.groovy and Assembler.properties into asm01.groovy and asm01.properties and asm02.groovy and asm02.properties to accomplish the task. That makes for a lot of updating to file.properties.

Script mappings for all application programs

dbb.scriptMapping = asm01.groovy :: /*.asm01 dbb.scriptMapping = asm02.groovy :: */.asm02 dbb.scriptMapping = Assembler.groovy :: /*.asm dbb.scriptMapping = BMS.groovy :: */.bms dbb.scriptMapping = MFS.groovy :: */.mfs

[rsjrny]

This was the final outcome of my enhancements to get individual application language files in the same directory as the application-conf. It's a lot less changes then my first attempt

Modifications to allow override properties to be maintained in a directory outside
of the startup path within an applications folder. this will suffix the 
applicationConfRootDir=/u/prodpc2/scripts/dbbuild/ with the applications name
allowing multiple application overrides in the same root directory

2 changes:
1. New props. value: applicationLanguageInAppConf=Y
2. a code change in build.groovy to read the prop.

The original code (lines 57 - 62):

            if (buildFiles.size() > 0) {
                if (scriptPath.startsWith('/'))
                    runScript(new File("${scriptPath}"), ['buildList':buildFiles])
                else
                    runScript(new File("languages/${scriptPath}"), ['buildList':buildFiles])
            }

Was modified to this (lines 57 - 66):

            if (buildFiles.size() > 0) {
                if (scriptPath.startsWith('/'))
                    runScript(new File("${scriptPath}"), ['buildList':buildFiles])
                else {
                    if(props.applicationLanguageInAppConf == 'Y')
                        runScript(new File("${props.applicationConfRootDir}/${props.application}/languages/${scriptPath}"), ['buildList':buildFiles])
                    else
                        runScript(new File("languages/${scriptPath}"), ['buildList':buildFiles])
                }
            } 

[dennis-behm]

Hi @rsjrny, I think, don't understand the root problem. You are writing:

I want to split the language.groovy and properties away from the product repositories so the languages and properties are NOT updatable by users of the repository.

zAppBuild needs to be seen as the central build framework implementation at your site. Only the build admin have update permission on this repository.

There is no need for anyone to access or modify it. The build admin provides the framework at a central location in USS, and developers point their User Build configuration to this path, like the pipeline definitions as well.

[rsjrny]

@dennis-behm

The reason I split the language files outside of the zAppBuild environment is this. If you have a better idea I am open to all suggestions

I have 15 separate products that I support. Each product has the same languages, we will work with HLASM for now.

Product 1 has 400 assembler programs 100 are assembled with proc hlasm01 and 25 are RENT,AC=0 overrides asm01 and 25 are RENT,AC=1 overrides asm02 and 50 are NORENT,AC=0 overrides asm03 100 are assembled with proc hlasm02 and 25 are RENT,AC=0 and 25 are RENT,AC=1 and 50 are NORENT,AC=0 100 are assembled with proc hlasm03 and 25 are RENT,AC=0 and 25 are RENT,AC=1 and 50 are NORENT,AC=0 100 are assembled with proc hlasm04 and 25 are RENT,AC=0 and 25 are RENT,AC=1 and 50 are NORENT,AC=0

There is also syslib difference between the .properties. So for the first set of 100 programs I need 1 assembler proc and 3 different sets of proc overrides

for the most part, the Assembler.groovy will work to replace PROCS hlasm01 - hlasm04 but the Assembler.properties is not sufficient. I need to be able to run Assembler.groovy with asm01.properties or asm02.properties or asm03.properties or asm04.properties. asm01 has different syslibs then asm02 and asm03 has different syslibs then asm01 and asm02 along with other differences.

The reason I split the languages into separate folders was that asm01 in product1 is completely different than asm01 in product2. I have the language split working just fine and it is exactly what I needed. I only needed to move application-conf and languages outside of the build directory. I left build-conf in its original location as you mentioned above

The lack of being able to use different properties for the same Assembler.groovy is what is forcing me to copy Assembler.groovy to asm01.groovy with asm01.properties and the same for asm02, asm03, asm04. All so I can specify different overrides.

[rsjrny]

Hi @dennis-behm ,

I have cloned the fork that uses the loadLanguageConfigurationFile and it does work for me with one exception. Unless I have missed something, it is a little too restrictive. I do not want my language configuration files in the build-conf/language-conf folder of zappbuild. I maintain them outside of the build application.

The fork would be perfect if it allowed me to supply the full path location of the override files. It would be great if if I could also do that for the language files.

I have 10 different products that I want to use zappbuild from one location but I need to specify the language-conf once for each of the 10 products because they have additional overrides for the same named property.

product1, langdeff01 is different than product2 langdef01. It would be a nightmare if I had to go and rename the thousands of lines I have in the 10 side decks.

to summarize,

supplying the ability to use a property for the full path of the language-conf folder and the fullpath of the zappbuild/languages would be wonderful

thanks,

russ