A library's package name is declared twice, and the two copies are used for different things, so a disagreement between them produces Java that does not compile rather than an error saying so.
|
config-*.yml |
the config: block at the head of model-*.yml |
| read into |
GeneratorConfig |
LibraryModel.Config |
libraryPrefix |
yes |
yes |
iconPackage |
yes |
yes |
amplifierPackage |
yes |
yes |
commonPackage |
yes |
yes |
countryCodeClass |
— |
yes |
modelFilePath, modelSourceFile, outputDir, resourceDir |
yes |
— |
They are not redundant, which is what makes it dangerous. GeneratorConfig decides where a file is written — getIconPackageDir() resolves outputDir against iconPackage. The model's Config is what the templates interpolate: ${iconPackage} appears 38 times across them, ${commonPackage} 8, ${amplifierPackage} 3, ${libraryPrefix} 4. So one controls the directory and the other controls the package statement and the imports inside it.
Set them differently and the generator cheerfully writes a file to io/github/ctgnz/jmsfx/hallux/ that declares package nz.co.ctg.hallux.jmsfx, and imports types from a package nothing produces.
How it surfaced
Renaming the hallux library's package in #106. Changing config-hallux.yml alone moved the files and left roughly half of them importing the old package — IconBounds, SymbolSetEnum and each symbol set's own package, all of which the templates emit from the model's copy. It looks like a partial rename rather than a configuration problem, which is the wrong place to start debugging.
Worth deciding rather than just deduplicating
Which one should own it? The model is what jmsfx-editor will edit (#7, #8), and a model that describes its own output package is self-contained. But a package name is arguably a property of generating a library rather than of the symbology it describes — jmsfx-battleorder is an overlay that carries no packages at all, and under #81 the base model's package would be the wrong answer for the library composed from it.
My inclination is that it belongs to the generator config, with the model's block dropped, and that the templates take it from there. But it is worth settling alongside the editor work rather than in isolation, since the editor is what will read and write that block.
Whatever wins, the other should be removed rather than validated — a check that they agree still leaves two places to edit.
Related: #7, #8, #81, #106.
A library's package name is declared twice, and the two copies are used for different things, so a disagreement between them produces Java that does not compile rather than an error saying so.
config-*.ymlconfig:block at the head ofmodel-*.ymlGeneratorConfigLibraryModel.ConfiglibraryPrefixiconPackageamplifierPackagecommonPackagecountryCodeClassmodelFilePath,modelSourceFile,outputDir,resourceDirThey are not redundant, which is what makes it dangerous.
GeneratorConfigdecides where a file is written —getIconPackageDir()resolvesoutputDiragainsticonPackage. The model'sConfigis what the templates interpolate:${iconPackage}appears 38 times across them,${commonPackage}8,${amplifierPackage}3,${libraryPrefix}4. So one controls the directory and the other controls thepackagestatement and the imports inside it.Set them differently and the generator cheerfully writes a file to
io/github/ctgnz/jmsfx/hallux/that declarespackage nz.co.ctg.hallux.jmsfx, and imports types from a package nothing produces.How it surfaced
Renaming the hallux library's package in #106. Changing
config-hallux.ymlalone moved the files and left roughly half of them importing the old package —IconBounds,SymbolSetEnumand each symbol set's own package, all of which the templates emit from the model's copy. It looks like a partial rename rather than a configuration problem, which is the wrong place to start debugging.Worth deciding rather than just deduplicating
Which one should own it? The model is what
jmsfx-editorwill edit (#7, #8), and a model that describes its own output package is self-contained. But a package name is arguably a property of generating a library rather than of the symbology it describes —jmsfx-battleorderis an overlay that carries no packages at all, and under #81 the base model's package would be the wrong answer for the library composed from it.My inclination is that it belongs to the generator config, with the model's block dropped, and that the templates take it from there. But it is worth settling alongside the editor work rather than in isolation, since the editor is what will read and write that block.
Whatever wins, the other should be removed rather than validated — a check that they agree still leaves two places to edit.
Related: #7, #8, #81, #106.