Overview
This page explains the rationale behind the plugin. It intentionally does not re-list the goal parameters: see the generated goal reference index for those.
Why a Maven plugin for Apache Hop?
Apache Hop projects are XML pipelines (.hpl) and workflows (.hwf) plus the metadata that drives them. The Hop editor offers a graphical canvas, but every repetitive, build-friendly step around that content - rendering diagrams, generating documentation, assembling a runtime distribution, running the flows and wrapping the CLIs - is manual and drifts quickly.
This plugin exposes those operations as plain Maven goals, so they become reproducible, versioned and always current from the build. It covers the whole lifecycle of a Hop project:
-
render - headless diagram generation,
-
generate-doc - per-flow documentation and index,
-
build - custom distribution assembly,
-
run - headless execution,
-
server / server-stop - Hop server lifecycle,
It follows the standard Hop project layout by default (diagrams at the project root, metadata/ for metadata, project-config.json for variables) and every input is overridable from the pom.xml.
The rendering approach
Rendering is the headless face of Hop. The render goal:
-
initializes the headless Hop environment,
-
injects the declared variables into a Hop variable space,
-
builds a metadata provider on top of the metadata folder so database connections and other metadata resolve,
-
discovers every supported diagram file, honoring include/exclude patterns,
-
loads each file as a Hop pipeline or workflow,
-
and writes one diagram per requested format under the output folder, keeping the source-relative path.
HOP ships headless painters and diagram exporters, so the whole rendering happens without opening a GUI. HopEnvironment.init() is idempotent and there is no shutdown API to call, so the goal is safe to invoke repeatedly (for example once per module) in the same JVM; process exit cleans everything up.
One distribution, many goals
build, run, encrypt, gui and server all share the same distribution assembly: they resolve and unpack a Hop client zip, merge the Hop project home (default src/main/repositories, into the canonical config/projects/<name> home) on top and differ only in the launcher script they execute. This keeps the whole toolchain consistent on a single resolved Hop version. Work is done under target/hop/<goal>, so the source project is never modified. When the merged project home provides a project-config.json, the project is registered in the distribution config/hop-config.json and activated on startup (-j <name> for the GUI, --project <name> for run/server), so your pipelines/actions are visible immediately.
Next steps
See Goals for the goal catalog, Usage for wiring and build integration, and the goal reference index for parameters.