Regularize determination of collection content file.


Guise Mummy supports a "content file", a resource stand-in for the content of a collection. Put another way, if one browses to foo/bar/, this file contains the content that will be shown.

Traditionally this has been an index.html file, such as foo/bar/index.html. Traditionally, instead of simply showing the content, the web server would redirect to the file. But the modern approach is simply to show the content of foo/bar/index.html when browsing to foo/bar/. With this approach foo/bar/index.html becomes an implementation detail, and in fact Guise Mummy hides it altogether from browsing.

The first versions of Guise Mummy hard-coded the name index.xhtml as the expected content file. Besides being inflexible, this causes problems with the support of HTML files in GUISE-111: if an index.html file is present, it isn't recognized as the content file, and a phantom index.xhtml source file artifact is generated.

Replace the hard-coded references to "index" files and allow the base filename (e.g. index) to be configurable. The configuration key is to be mummy.collectionContentBaseNames and accept a collection (normally a list) of strings.




Garret Wilson
March 19, 2020, 4:38 PM

Currently if two content files are indicated, e.g. foo.html and bar.html, the same names will be used during mummification. For local serving this poses no problem, as Tomcat allows multiple "welcome files" to be specified. But AWS S3 only allows one "index document" to be specified and needs to be documented. For now projects should specify only one content base name, and AWS S3 will issue a warning if multiple values are given.

Ideally we should normalize the welcome filename to the first filename when mummifying the site; there is no need to have multiple of them when we control the generation. We can do that in a separate ticket, though: GUISE-120.



Garret Wilson


Garret Wilson




Fix versions

Affects versions