Help that lives inside the Eclipse IDE. HTML topics, XML table of contents, and context plug-in mappings the Eclipse Help viewer expects — so your documentation opens in the same window as the tool your users are already working in.
Eclipse Help is ePublisher's output for products built on the Eclipse platform. It is the right choice when your application is an Eclipse-based IDE, an Eclipse plug-in, or any Java tool that already ships with the Eclipse Help runtime — and you want help that opens directly inside the Eclipse Help viewer rather than in a browser tab.
Output can be delivered as the complete folder of individual files or compressed into a single Java archive
(.jar) for distribution alongside your application or plug-in.
Every topic rendered to standards-compliant HTML, ready to be served by the embedded Apache Tomcat instance the Eclipse Help viewer runs internally.
Eclipse-format toc.xml describing the navigation hierarchy the viewer presents in its navigation pane.
A generated plugin.xml that maps Eclipse plug-in IDs to topics, so Eclipse developers can wire help into specific UI controls inside the IDE.
Author-controlled descriptions surfaced in the Eclipse help dialog when a user invokes context help on a control.
Search built in to the Eclipse Help viewer, indexed at generation time and available to users without any server-side service.
Author-defined index markers carried into the Eclipse navigation pane alongside the table of contents.
Eclipse Help is the right output when documentation needs to live inside an Eclipse-based environment. Three deployment patterns drive most adoption:
If your product is built on the Eclipse platform — a developer IDE, a modeling tool, an EDA package, a scientific workbench — Eclipse Help is the native help format users expect. Pressing F1 in the IDE opens the help directly inside the Eclipse Help viewer alongside the tool itself, without the user leaving the application or switching to a browser.
The same Eclipse Help content can be served as an Eclipse Infocenter — a stand-alone help server backed by the Eclipse Help runtime that delivers the helpset to any modern browser. Infocenters are a fit for hosted documentation portals where the publisher already standardizes on Eclipse infrastructure.
Eclipse application developers map UI controls to specific topics by referencing context plug-in IDs. ePublisher authors declare those IDs in the source documents using a Context Plugin marker, and the generated plugin.xml feeds them straight to the developers — no separate ID coordination, no out-of-band mapping file to keep in sync.
Eclipse Help is one of several outputs ePublisher generates from the same source project. Choosing it over a browser-based output is a question of where the help needs to live.
Right when your product is an Eclipse-based application or plug-in and the documentation needs to open inside the Eclipse Help viewer — same window, same shortcut keys, same plug-in lifecycle as the rest of the IDE. Also right when JavaScript cannot be assumed in the target environment but a Java runtime is already present.
ePublisher's flagship online output: responsive HTML5 portal with advanced search, GA4 analytics, AI-assisted features. Right when publishing a customer-facing documentation portal rather than help that lives inside a desktop tool.
If your Java application is not built on the Eclipse platform, ePublisher's other Java-based help outputs — Oracle Help and Sun JavaHelp — may be a better fit. Eclipse Help specifically targets the Eclipse Help runtime.
Eclipse Help is generated from the same ePublisher source project as Reverb 2.0, Dynamic HTML, PDF, and the legacy help formats. Authors work in their preferred document tool — Adobe FrameMaker, Microsoft Word, DITA XML, or Markdown — and ePublisher applies the project's Stationery to produce each target format. Conditional content, variables, indexing, table-of-contents structure, and context-sensitive help all carry across formats consistently.
Eclipse plug-in IDs are declared inline in the source documents using ePublisher's Context Plugin marker. The generated plugin.xml reflects exactly what the authors wrote, so writers and Eclipse developers stay in sync without a separate coordination file. The same applies to topic descriptions for the Eclipse context-sensitive help dialog.
ePublisher ships a standalone Eclipse Help viewer so authors can preview generated output without installing the full Eclipse SDK. The same generated files run identically inside the production Eclipse Help viewer — what you see in preview is what your users will see in the IDE.
Eclipse Help output is delivered either as the complete folder of individual files or as a single compressed .jar archive. Java application developers choose the form that fits their plug-in packaging and distribution model — ePublisher generates both formats from the same publishing run.
Eclipse Help relies on the Java-based Eclipse Help viewer rather than a JavaScript-driven web framework. For deployments where JavaScript availability cannot be assumed but a JVM is present, Eclipse Help delivers a complete navigation, search, and indexing experience without depending on browser-side scripting.
Eclipse Help is one of several outputs ePublisher generates from the same source project. The same documents that produce Eclipse Help for an IDE plug-in can also produce Reverb 2.0 for a customer-facing portal, Dynamic HTML for embedded in-product help, PDF for printable user guides, and legacy formats like HTML Help, Oracle Help, and Sun JavaHelp — all in a single publishing run.
Reaching multiple audiences with consistent content means writing once, branding once, and shipping everywhere your readers are.
See how Eclipse Help output fits your IDE, plug-in, or Infocenter deployment. Walk through your use case with us, or start a free 14-day ePublisher trial.