Bug 796009

*** Bug 795216 has been marked as a duplicate of this bug. ***

Done in 0.22.0.

A few changes from the above details:

The output structure is now:

/home/jwulf/scratch/Content_Spec_Processor/
/home/jwulf/scratch/Content_Spec_Processor/csprocessor.cfg
/home/jwulf/scratch/Content_Spec_Processor/post-Content_Spec_Processor.spec
/home/jwulf/scratch/Content_Spec_Processor/assembly/Content_Spec_Processor-publican.zip
/home/jwulf/scratch/Content_Spec_Processor/assembly/publican/publican.cfg

This was done since it is redundant to have the $TITLE twice in the same directory structure. It also makes it easier to navigate as by going directly to the publican folder you can run publican commands straight away. It also creates a more meaningful zip archive as the ZIP now contains the program that it was built for in its file name.

More comments about the new client and configuration files to come.

New configuration file:

-----------------------------------------------
[directory]
# Main directory to store content specifications
root = 

[publican]
build.parameters = --langs=en-US --format=html-single,html
preview.format = html-single

[servers]
default.url = http://localhost:8080/TopicIndex/
default.username = 

production.url = http://skynet.cloud.lab.bne.redhat.com:8080/TopicIndex/
production.username = 

test.url = http://skynet.usersys.redhat.com:8080/TopicIndex/
test.username = 
-----------------------------------------------

The default.url must exist. The username parameter isn't required and will default back to the default.username if no username is set in the other server parameters.

The root parameter in directory is the root directory to store all the content specifications. If it it null then the current working directory will be used.

The publican configuration files define which commands publican should use to build the specs and to preview them.

To go with the last comment servers in the csprocessor.cfg will will never match to a default server. This is because the default URL is designed for commands that don't use the csprocessor.cfg. It must be defined elsewhere i.e:

csprocessor.cfg:
----------------------------------------------------------
SPEC_ID = 6192
SERVER_URL = http://localhost:8080/TopicIndex/
----------------------------------------------------------

csprocessor.ini
----------------------------------------------------------
[servers]
default.url = http://localhost:8080/TopicIndex/
default.username = lnewson

local.url = http://localhost:8080/TopicIndex/

....
----------------------------------------------------------

The client was completely rewritten to go with the removal of the server. The client now uses a modified version of JCommander (http://www.jcommander.org/) to parse the arguments. The new list of commands can be seen below:

Usage: csprocessor [options] [command] [command options]
  Options:
   --config <FILE>            
   --help                     
   --host, -H <URL>           
   --username, -u <USERNAME>  
  Commands:
    assemble      Builds and Assembles a Content Specification so that it is ready to be built
    build      Build a Content Specification from the server
    checkout      Checkout an existing Content Specification from the server
    create      Create a new Content Specification on the server
    checksum      Get the checksum value for a Content Specification
    list      List the Content Specifications on the server
    preview      Build, Assemble and then open the preview of the Content Specification
    pull      Pull a Content Specification from the server
    push      Push an updated Content Specification to the server
    revisions      Get a list of revisions for a specified ID
    search      Search for a Content Specification
    validate      Validate a Content Specification

The pull command will create a backup file when it pulls a content specification. This is done to protect overwriting the changes of local files.

Another difference from the original guidelines is the assemble command will also build the book using publican since this is actually part of assembling a book.

So the Assemble command will build the book, unzip it to the publican directory and then build using publican. You can stop the book from being rebuilt by the processor by using the "--no-build" option.

The preview command will build the book, unzip it to the publican directory, build it using publican and then open the file specified by the "preview.format" config parameter. You can stop the building or assembling by using the "--no-build" or "--no-assemble" commands.

If no "build.parameters" is set it will default to "--langs=en-US --format=html-single".

If no "preview.format" is set then it will default to "html-single".

Known issues:

- If you try and use the preview command with Google Chrome as the default web browser and no open instance, Chrome fails to start properly. This appears to be an issue with the Java Runtime library.

More Information:

The Preview and Assemble commands also have the ability to be used with an ID. When this is done the build will behave in the same manner it did in the old version, where a <TITLE>.zip is created in the current working directory (cwd). 

From there the assemble will extract the zip into cwd/<TITLE>/ and then run publican from that directory in the same manner as assembling using a csprocessor.cfg. The preview is also no different except it opens it from the cwd/<TITLE>/tmp/en-US/ directory.

Additional feature to be implemented:

A new status command should be added so that a user can check if their current post processed spec is the same version that exists on the server. This makes it easier to use when multiple people are working on the same Content Spec.

Added the status command.

It will print a message or error stating that the content specification is up to date or if it is out of date a message is display stating to get the latest download it using the pull command.

Also one component that I added is that when using the assemble command it will delete everything in the assembly/publican/ folder. This is done to ensure that the publican build has only the files from the latest build. While having old files shouldn't cause an issue for publican it could confuse the user if they see those old files in there.

*** Bug 766408 has been marked as a duplicate of this bug. ***

*** Bug 766413 has been marked as a duplicate of this bug. ***

*** Bug 766406 has been marked as a duplicate of this bug. ***

Verified in cspclient-0.23.2-1.