Hide Forgot
If a user were to attempt to use a topic that had content that couldn't be used in an Initial Text container, then the validator will mark the content spec as invalid and populate the "failedSpec" field. However there really isn't anything wrong with the spec itself and the issue lies in the topic, so if the topic is fixed then it should be able to build. This however isn't the case because the csprocessor will check to see if the "failedSpec" field is populated and if so print a warning like: The Content Specification has validation errors, so using the latest valid version. As such we should probably look at moving those checks over to the builder, as that is when it will cause an issue.
Fixed in 1.9-SNAPSHOT build 201407221239 The core of this logic has now been moved to the builder validation step, so the error will now appear in the compiler output in the builder. Additionally the content spec validator will now only print warnings to say that the topics xml is currently invalid, so that users still get a rough idea that the topic cannot be used in it's current state. Note: I've also cleaned up the custom topic validation code as we current had two instances of it (one for the rest server and one for the builder). See https://github.com/pressgang-ccms/PressGangCCMSContentSpec/blob/devel/src/main/java/org/jboss/pressgang/ccms/contentspec/utils/CustomTopicXMLValidator.java for the shared implementation.
Verified that a spec with an initial topic container hosting more than one topic where one of them has nested sections generates the appropriate warning and can still be built locally. The only limitation I found was that specs built with obviously out of place topics (like using an abstract in an initial text block) could produce the same scenario of an entire spec being invalid due to a single topic. But I can't think of a valid workflow where special topics are repurposed to normal topics, so these spec validation errors are still appropriate.