Factor out mummifier packages
The base io.guise.mummy package is getting too cluttered with all the mummification artifact types. We need to split them out into some subpackages, similar to how we have an io.guise.mummy.deploy subpackage with its own io.guise.mummy.deploy.aws subpackage.
There are a lot of unknowns, and I'm not completely satisfied with the new package structure (or even with the current object model), but for now I think it's an improvement and is less cluttered.
One approach is that DirectoryArtifact should live near DirectoryMummifier, and many of the abstract file artifact types should be moved to the io.guise.mummy.mummify package. As mentioned above, it is unknown how we will factor out "content source" or leave this as an artifact implementation variation.
So if we leave *File*Artifact classes in io.guise.mummy, would we leave DirectoryArtifact there, too? Or should DirectoryArtifact really be named DefaultCollectionArtifact?
The next question that arises is: is a mummifier for a directory a "directory mummifier" or a "collection mummifier"? In resource terms the thing being created is a "collection". But in the file system we're creating a "directory". Analogous to the "page mummifier", this would be a "collection mummifier", and "directory" is just one (currently the only one) of the sources we can draw from to create a collection.
But then we have the tenuous distinction between "composite artifact" and "collection artifact". At the moment we're saying that "composite" means that it is made up of other artifacts, but collection (a type of composite artifact) means that it actually has collection children. So for example a DirectoryArtifact considers all the contained files to be "comprised" artifacts, but only the files that are not the "content" index file are considered "child" artifacts. Complicating this picture is that after implementing blog posts, the "child artifacts" may not be direct child resources; this means a Guise Mummy "collection" is not an exact match with a "collection URI".
For now the questions are:
Do we think of the mummifier as a "directory" mummifier or a "collection" mummifier?
Do we leave the CollectionArtifact a general "thing" in the io.guise.mummy package?
For the last point, we have general mummy code (e.g. in BaseMummyContext) that references CollectionArtifact.getChildArtifacts(). Maybe that's OK, but it's a different approach than PageArtifact, where the more general code doesn't pay attention to the class but instead pays attention e.g. to the navigability of the artifact.
After more thought, I think it's clear that a "collection" is a different type of thing altogether than "all the other" artifacts. It in a different category altogether than "page versus image" for example. (But is it really? Might we eventually just think of any resource as being able to have children, as we did with Marmot? Then the "content" or index file would be an implementation detail. But then again this is a static site generator, and we should jump too far ahead in abstractness unless we know what's needed.) If a "collection" is a different type of artifact in the tree, than the Collection interface definitely needs to be in io.guise.mummy for now, i.e. at the same level of all the other general artifacts. And if we think that there are other ways we may make collections of things in the future (e.g. from a database or feed), we need to put DirectoryMummifier in a io.guise.mummy.mummify.collection package. (We might later have an AbstractCollectionMummifier that DirectoryMummifier and NewsfeedMummifier extends. But this is all very conjectural.)
Considering further the meaning and nature of artifacts (from above), it may be that the creation of artifacts is even more indirect than it is now. If we allow artifacts to be derived from various sources (e.g. a relational database), and picture them as mere placeholders and conduits, then the actual creation of an artifact my be somewhat hidden from a mummifier. Instead, the thing calling Mummifier.plan() might instead pass some sort of artifact factory, and the mummifier would pass a description and e.g. a flag for whether the artifact is navigable, and the factory would determine which sort of artifact to create (based upon whether it is being pulled from a file system, database, or whatever).
One problem with this train of thought is that so much of the mummifier still depends on knowledge of the file system, such as loading sidecar files (as we soon will do). And loading a description right now depends on the mummifier knowing how to access the file system. Maybe we would have another level of indirection, with some source resource object that knows how to load content, and pass that to the mummifier?
A lot of this is conjectural and vague. It is probably best not to muck around much with the form of artifacts yet until more experience is gathered. But a couple of things are starting to become more apparent.
Perhaps the planning mummifier should not decide whether something is navigable, but rather the mummifier of the parent. For example when a directory creates a content artifact for the "index" file, it relies on the planning mummifier to assign navigability (in this case erroneously making the file navigable). Currently this doesn't pose a problem because the directory mummifier leaves out the content artifact from the list of children it uses when it creates the directory artifact.
We are using the term "page" in subtly different ways between artifacts and mummifiers. For PageArtifact, it simply means an artifact we can navigate too (not necessarily an HTML page, but really that's the only type that would exist for now, although I suppose it could be a text file or some other markup file or even an image one could navigate to). For PageMummifier, we're referring specifically to mummifiers that product HTML files (which in theory might not even be navigable; see the above point, for example).
In the meantime perhaps these inconsistencies can be lessened if we move page and directory artifacts into the page and directory mummifier packages, and revisit those issues in the future after more experience.