Hop Marketplace

You can open the marketplace dialog from:

On first use you may also see the welcome page that introduces the marketplace:

The main Plugin Marketplace dialog has three tabs:

After install, apply, or uninstall, restart Hop so the plugin registry reloads.

Use this tab to work with the local optional-plugin catalog:

Install uses the primary repository first, then other enabled repositories (see Repositories tab).

This tab embeds the full environment editor (no separate “Edit…” window). It is the GUI equivalent of hop marketplace validate / apply and of editing hop-env.yaml by hand.

Configure the global marketplace repository list (stored under marketplace in ${HOP_CONFIG_FOLDER}/hop-config.json — the same config the CLI uses):

Add or edit a repository with id, name, URL, optional credentials, and primary/enabled flags:

Import from URL… adds a repository from a definition published on the web, so a marketplace operator can hand out one link instead of a file and a set of instructions.

Because the address is typically pasted from an email, a chat message or a web page, the import is deliberately narrow:

One field is not merely descriptive: a definition that sets primary: true becomes the primary repository on import and demotes the current one, so every install tries it first. If that repository is private and the credentials are not set yet, installs that used to work will fail until they are. Check that field before importing a definition you did not write, and use Set primary to put the order back.

Importing the same file from disk keeps any credentials it contains. That is what makes an administrator-provisioned definition work for an internal rollout: the file was placed there deliberately, where a URL is only ever a pointer.

When the Projects plugin is installed, each lifecycle environment can store marketplace-specific attributes (namespaced under the marketplace group). On the environment properties dialog, open the Marketplace plugins tab:

Typical options:

If On enable is unset, purpose-based defaults apply: Production → enforce, Testing / Acceptance → warn, Development / CI-style purposes → off.

This complements hop-env enforceOnRun (checked at hop-run) and the Environment tab Validate / Apply actions (manual checks from the marketplace dialog).

Installs missing plugins and dependencies declared in the environment file. Already-satisfied plugins are skipped.

Examples:

Behaviour notes:

Always restart Hop after a successful apply when new plugins were installed.

Compares the local install to the environment file without downloading or installing anything. Useful in CI as a pre-flight check.

Exit codes:

What counts as drift (always hard-fail):

Examples:

When a hop-env file is found and enforcement is on, hop-run validates before execution and aborts on missing plugins/deps or version mismatches (same checks as validate without --strict).

Enable enforcement either:

If a hop-env file is present but enforceOnRun is false and the property is unset, hop-run only logs that the file was found and skips the check.

Used by validate (when -f is omitted) and by hop-run:

Full example:

A password on a repository entry is written to hop-config.json — and to exported repository definitions and environment files — obfuscated with Hop’s two-way password encoder, the same Encrypted 2be98afc… form used for Hop server and database passwords. Configurations written by older versions are read as-is and re-encoded the next time they are saved.

Obfuscation is not encryption: the encoder key is not a secret, so anyone holding the file and a Hop install can recover the password. It stops credentials being read over a shoulder, in a screenshot or in a diff — nothing more.

To keep the secret out of the file altogether, put a variable or a variable resolver expression in username / password instead of the credential:

Variables are stored exactly as typed — there is nothing secret to obfuscate — and are resolved when the repository is contacted, so the secret lives in the variable rather than in the file.

Marketplace repositories are client-wide rather than project-bound, so ${…​} resolves against client-level variables only: JVM system properties (-DACME_TOKEN=…, for example through HOP_OPTIONS) and variables described in hop-config.json. Project and environment variables are not visible here, and neither are plain shell environment variables — for those, use the HOP_MARKETPLACE_* names above. A variable resolver expression such as #{vault:hop/marketplace:token} is looked up in the active metadata, so a secret manager works as well.

A variable that is not set is sent to the server unresolved, and the resulting 401 says so.

The HOP_MARKETPLACE_* environment variables above remain the simplest option when nothing at all should be written to the configuration.

Because the global variables are offered to every repository — including public ones such as the ASF repository and Maven Central, which reject unknown credentials with HTTP 401 instead of ignoring them — a request that fails with 401 or 403 using credentials that came only from the environment is retried once anonymously. Credentials configured on the repository entry are treated as deliberate and are never dropped, so those failures are reported as-is.

The same credentials apply to hop marketplace repo import <https URL>, so a shared repository definition can be hosted in a private repository. No repository entry exists at import time, so only the environment variables are available there.

Installing works against any Maven repository, because downloads use plain Maven layout. Listing plugins (browse: true) needs a repository-manager API, and those differ per product. Set browserType on the repository to choose:

auto selects forgejo for URLs containing /api/packages/ (for example https://forge.example.org/api/packages/acme/maven) and nexus otherwise. On Forgejo, packages are named groupId:artifactId and each candidate version is checked for a plugin zip, so plain library jars are not listed as installable.

For a repository manager with no supported search API, publish a catalog YAML and set catalogUrl on the repository instead — discovery then reads that file and never calls a registry API. The catalog is fetched with the repository’s Basic credentials when they are configured, so it can live in a private repository.

Plugin zips do not have to be served from a Maven repository at all. Set urlTemplate on the repository when they come from git release assets, a static file host, or a CDN:

Supported placeholders are ${groupId}, ${groupPath} (groupId with dots replaced by slashes), ${artifactId} and ${version}; an unrecognised placeholder is reported as an error instead of producing a confusing 404. When urlTemplate is set, the repository url is not used for plugin downloads.

Such a host serves no Maven metadata, so versions must be exact: combine urlTemplate with a catalogUrl that pins each version. SNAPSHOT resolution does not apply, and live browsing cannot list release assets.