Creating a Composition Job

A composition job assembles WebWorks Reverb 2.0 output that has already been published into a single website, without rebuilding any of it. Each contributing help set is produced by its own job, and the composition arranges the published results under one shell and one table of contents. Because nothing is rebuilt, a composition runs in seconds, and one team can republish its own manual without touching anyone else's. For the concepts behind this, see Federated Parcel Composition.

Composition jobs use a .wacj (WebWorks AutoMap Composition Job) file extension and appear in the ePublisher AutoMap main window alongside your other jobs. The jobs a composition references are called its members.

To create a composition job

  1. Start ePublisher AutoMap.

  2. On the File menu, click New Job.

  3. Select Compose published parcels into a website (Composition Job) on the New Job window, and then click OK.

  4. Type a name for the composition job, and then click OK.

    ePublisher AutoMap creates the composition in your job folder and opens the Composition Job window.

  5. In the Member Jobs area, click Add and select the jobs you want to compose. The list shows the jobs in your job folder; jobs that are already members appear selected and unavailable. To use a job or project stored somewhere else, click Browse at the bottom of the list and select a job (.waj) or project (.wep or .wrp) file.

  6. Set the Role for each member. One member should have the role Shell — it supplies the site chrome that the composed site's entry page comes from. Members that supply content have the role Parcel. Leave the role set to Infer to let each member's own job decide what it publishes.

  7. Select or clear the check box in the Build column for each member. For more information, see Built Members and the Build Flag.

  8. In the Output target list, select the output target the composition builds and composes through, or leave it set to (automatic) to have ePublisher AutoMap select the target from each member.

  9. In the Deployment area, specify where the composed site is published:

    1. If you want the composition to carry its own destination definition, select Defined in this job, type a Destination name, select Folder or Amazon S3 as the Deployment type, and complete the fields for that type. A definition stored in the job travels with the job, so a machine that has never been set up can still run it.

    2. If you want to use a destination already defined on this computer, select Deploy Destinations and select the destination from the list. For more information, see Defining Output Destinations.

  10. In the Merge Settings area, choose how the composed table of contents is built:

    1. If you want every published help set at the destination to appear in the site, select Automatic (compose every parcel found at the destination).

    2. If you want to declare the table of contents yourself, select Custom, and then use Add Group to place a published group and Add Container to create a folder to hold groups. Drag entries onto a container to nest them, or use Up and Down to reorder them. Select Also include newly published parcels not listed above to have groups you did not list appear in the site as well.

  11. Click OK to save the composition job.

Note: The Output target list offers only targets whose output format supports composition, which today means WebWorks Reverb 2.0. Whichever target each member uses, every member must produce the same output format. Target names may differ from team to team; formats may not.

The Target column appears in the members grid only when a member declares its own output target in the composition job file. That declaration overrides the Output target selection for that member, so the column is shown read-only to make the override visible rather than silent. To change or remove it, edit the composition job file.

If the composition references a deploy destination that is not defined on this computer, the Destination list still shows that name and keeps it selected rather than dropping it, so you can edit a composition on a machine that does not have the destination without silently losing the reference. The name must resolve on the machine that runs the job — from a destination defined there, from a definition carried in the job, or from a definition supplied on the command line.

Built Members and the Build Flag

The Build column decides who publishes each member, and it is the one setting that changes what a composition does.

Build cleared

The member is published independently by its own job, on its own schedule. The composition does not build it — it reads the output that member already deployed to the destination and composes that. Use this when separate teams own their manuals and release on their own cadence.

Build selected

The composition builds the member itself and deploys it to the composition's destination, whatever destination the member's own job names. Use this when one composition owns the whole publication and a single run should republish the site end to end.

One composition can mix the two, member by member. Compositions you create in ePublisher AutoMap select Build for each member you add; a composition file written by hand leaves it cleared unless the attribute says otherwise.

When the composition builds a member, it also sets that member's deploy scope from its role, so a member cannot publish the wrong slice of its output. From the command line, the same redirection is available as the --destination option. For more information, see CLI Syntax and Reference.

For a member the composition does not build, ePublisher AutoMap compares the destination that member's job declares against the composition's own and warns when they differ, or when the member declares none — in either case the composition would be assembling output that the member never delivers to the destination being read.

How the Output Target Is Chosen

A composition composes through one output target per member, and it decides which one before any member builds. The choice is made explicitly, never by taking the first target that happens to work. For each member, ePublisher AutoMap applies the first of these that is present:

  1. The member's own declared target, shown read-only in the Target column.

  2. The composition's Output target selection, which applies to every member that does not declare its own.

  3. Automatic detection, used when Output target is set to (automatic) and the member declares no target of its own.

Detection never reaches past what the member itself says it produces. The candidates are the targets the member declares — the targets listed in a job, preferring the ones the job is set to build, or the targets in a project. Exactly one candidate whose output format supports composition selects it. If more than one does, the run stops and the message lists them so you can name the one you want; if none does, the run stops and the message names the member's targets and the formats they use.

Whichever way the target is chosen, every member must produce the same output format. Target names can differ from team to team; formats cannot. ePublisher AutoMap checks all of this before the first member builds, so a mismatch costs you a message rather than a long build.

When a Target Cannot Compose

The composition's shell member supplies the format the composed site is built from. If that member's selected target uses an output format that does not support composition, the run stops with a message naming the format:

The shell member's selected target uses format 'WebWorks Help 5.0', which does not support
federated composition; the composition needs a Reverb 2.0 (compose-capable) shell target.

Resolve it by selecting a WebWorks Reverb 2.0 target for the shell member — in the Output target list, or on the member itself — and then run the composition again.

When a Published Parcel Does Not Match the Shell

The composition checks the output it finds at the destination as well as the targets it is given. Each published parcel records the output format and the release that produced it, and the composition compares those against the shell's. A parcel published by a different format, or by a different release of the same format, cannot share the composed site's runtime, so the composition warns and leaves that parcel out rather than failing:

[WARN] Member 'Installation Guide': the output deployed at the destination was published by
WebWorks Reverb 2.0 2025.1, but this composition's shell uses WebWorks Reverb 2.0 2026.1, so
it cannot be included. Rebuild and redeploy it with the current version, then run this
composition again.

The rest of the site composes normally and the omitted parcel simply does not appear. Rebuilding and redeploying that parcel with the same version of ePublisher the shell was built with, and then running the composition again, brings it back into the site. Output published before parcels recorded their format is not compared, so an older parcel is not skipped on this account alone.

If every parcel found at the destination is skipped this way, the composition has nothing left to assemble and reports that it found deployed output but that none of it is usable, pointing you at the warnings above it in the log.

Last modified date: 08/17/2026