Problem:

If you use the Content Types feature to define workspaces and node types, and you have JCR content bootstrap files that rely on those Content Type definitions (typically in a modules 'mgnl-bootstrap' directory, or in the WEB-INF/bootraps/common directory), then the content will not be correctly installed at install time. When the system tries to bootstrap the content, it has not yet processed the Content Types and so the workspace does not exist yet.

Implemented in this ticket:

To bootstrap content, when using Content Types, use the Content Importer feature. Do not use the " WEB-INF/bootraps/common" feature.

The following capabilities have been added to the Content Importer feature.

• In addition to magnolia.content.bootstrap.dir property, this ticket introduces magnolia.content.bootstrap.pattern which specifies wildcard pattern (glob). When not used, the behavior of content-importer is identical (the pattern defaults to *. {yaml,xml})

• Property magnolia.content.bootstrap.initial=true (false by default) makes all files matching the pattern bootstrap at the startup. If the content with same path already exists, the import task is created instead.

Note - if you use the bootstrap.initial property, then you will recieve additional import tasks at every system restart. You can workaround  this by setting the property to false after the initial import. Or by removing the bootstrap files from the configured directory once they are imported.
This behaviour is addressed in https://jira.magnolia-cms.com/browse/MGNLCI-25

Copied from a documentation comment from uscheidegger 

If you have bootstrap data using that namespace and workspace, (defined in a CT yaml definiitons)  things will fail miserably.

After manually adding a workspace definition to the module descriptor, Magnolia only complains about the unknown namespace. 

So it seems like Magnolia should read the contentTypes definitions first, before bootstrapping anything. Of course this will hardly be possible, if the contentTypes are defined in JCR. 

IMO, the Magnolia startup code needs to be adapted:

• When the repo config is read from the module descriptor files, Magnolia should also check for content type definitions files.
• OR at least name space definitions in module descriptors should be supported.
  • However this would be a bit of a compromise as it would force us to keep the workspace and namespace definition in the module descriptor and  the content type definition.