Hop Maven Plugin

build : assembles a custom Apache Hop distribution. It downloads (or resolves through Maven) the configured Hop client zip, unzips it safely into a hop/ folder under workdir, enriches it with extra JDBC drivers, libs, javaagent jars, custom transforms, marketplace plugins and in-place jar overrides, then merges the baseDirectory content on top (so user files win). Finally it packages the result as a zip and optionally attaches it to the build. This mojo is also the base for the run/encrypt/gui/server goals, which reuse the very same distribution assembly and only differ in the script they execute.

encrypt : runs the hop-encrypt.sh / hop-encrypt.bat launcher of a Hop distribution to (de)crypt a password string. Reuses the whole distribution assembly + repository merge inherited from ; the strings to (de)crypt are passed through args . The project registration still applies (so the merged project is available) but no project activation argument is appended: the hop-encrypt launcher has no project option.

generate-doc : generates documentation pages for Apache Hop pipelines (.hpl) and workflows (.hwf) from the same discovery logic as the render goal (see ). For each Hop file it produces a documentation page (AsciiDoc or Markdown) with an overview, the declared parameters, the steps (transforms/actions) and the hop flow, a reference to the rendered diagram, and an optional launch script. The index page is generated from the Hop files themselves (no configuration required), with optional io.yupiik.hop.maven.documentation.Enrichment overrides for the human-written prose and ordering. When includeImage is enabled the render diagram logic is reused to also emit the image files next to the docs; when includeMd is enabled the pages are mirrored as Markdown plus an llms.txt file (see https://llmstxt.org ). The human prose is supplied either inline through enrichments or, by convention, through a per-artefact AsciiDoc file in enrichmentLocation (src/main/hop/documentation). A documentation file keeps the narrative order of the page: its overview (the prose before the first ==), its == sections and the launch script are rendered in the order they are written, and the generated sections (configuration, steps, flow, diagram) can be placed exactly where the thread needs them with a reserved heading == :configuration, == :steps, == :flow or == :diagram. Prose that follows a heading stays under it and nested === headings are preserved. Inline enrichments (no ordered file body) keep the canonical order Overview, Configuration, Steps, Flow, Diagram, Script, then the extra sections.

gui : launches the Hop GUI (hop-gui.sh / hop-gui.bat) of a resolved distribution. By default the GUI is started in the background (waitFor=false) and the user closes the window to stop it. When a Hop project home is merged (the default src/main/repositories or an explicit repository containing a root project-config.json), the project is registered in the exploded distribution config/hop-config.json (project name from the JSON name field, else the repository folder name; home = the canonical config/projects/<name> folder) and made the defaultProject, then the GUI is started with -j <name> so the project and its pipelines/actions are active on startup. Only the workdir copy is written, never the source project.

render : renders Apache Hop pipelines (.hpl) and workflows (.hwf) as diagrams. Diagram files are discovered from sourceFolder (recursively, honoring includes and excludes), the project variables and metadata are resolved, then one diagram per requested formats is written under targetFolder preserving the source relative path. HOP files load headlessly so the goal is well suited to CI builds.

run : resolves a Hop distribution (either the one built by the build goal and attached as a zip, or a distribution coordinate), unpacks it in the working directory, merges the configured repository on top (so project-config.json, repositories/ and metadata/ land in the canonical config/projects/<name> project home) and then runs a pipeline or workflow via hop-run.sh / hop-run.bat. The pipeline/workflow to run is selected either with the pipeline/workflow parameters (they are resolved by Hop inside the merged project home) or directly with a -f/--file argument in args (manual mode: no -f is added and the automatic project activation is suppressed). When a -r/--runconfig argument is present it takes precedence over the runConfig parameter.

server : launches the Hop server (hop-server.sh / hop-server.bat) of a resolved distribution. By default it is started in the background (waitFor=false); stop it with the server-stop goal which sends the authenticated /shutdown request. When a Hop project home is merged (the default src/main/repositories or an explicit repository containing a root project-config.json), the project is registered in the exploded distribution config/hop-config.json and activated with --project <name> (the server launcher parses it like hop-run).

server-stop : gracefully stops a running Hop server by sending the authenticated /shutdown request that Hop Server exposes (it registers a JVM shutdown hook on it). The target host/port and whether authentication is enabled are read from serverConfig (hop-server.xml, defaulting to the server goal workdir); stopHost/ stopPort are only a fallback when the config file is not present. After the shutdown request the mojo waits up to shutdownTimeoutMs for the port to free up.