Package com.vaadin.flow.plugin.maven

Class InstallDevCliMojo

java.lang.Object
org.apache.maven.plugin.AbstractMojo
com.vaadin.flow.plugin.maven.FlowModeAbstractMojo
com.vaadin.flow.plugin.maven.InstallDevCliMojo
All Implemented Interfaces:
com.vaadin.flow.plugin.base.PluginAdapterBase, org.apache.maven.plugin.ContextEnabled, org.apache.maven.plugin.Mojo
@Mojo(name="install-dev-cli", requiresDependencyResolution=TEST) public class InstallDevCliMojo extends FlowModeAbstractMojo
Installs the vaadin-dev CLI and its agent skills into the project.

Creates .vaadin/vaadin-dev (plus the .ps1 and .cmd launchers), the shared instructions under .agents/skills/vaadin-devloop/ and the Claude adapter under .claude/skills/vaadin-devloop/. No jars are staged into the project and no agent configuration is touched - the CLI resolves the dev-loop daemon from the project's own dependencies at first use.

It also provisions HotswapAgent into ~/.vaadin/devloop, which is the only asset the loop downloads rather than resolving from a Maven repository. That is deliberately the goal's job and not the first vaadin-dev start: an image built with network access and developed in without it - a container, a sandboxed agent environment - would otherwise install fine and then fail to start the loop at all. Once the goal has succeeded, nothing in the loop needs the network again. Machine-level, so nothing lands in the project and one download serves every application on the machine.

The provisioning runs out of the daemon jar the project itself resolves - the same one the CLI will run - so the pinned agent version is the version the running daemon goes on to ask for. Hence the dependency resolution this goal requires, and hence no scope filter when looking for it: the daemon travels in as an optional dependency of the dev server, and a project is free to declare it provided or test instead.

Everything it writes is meant to be committed, like mvnw: it is project tooling, and the point is that every developer and every agent on the repository gets the same instructions. It is also rewritten whenever it differs from the shipped copy, so a fix reaches a project by re-running the goal - add your own skill beside these rather than editing them.

Unbound, so it never runs as a side effect of a normal build. Run it on the application module: in a reactor that means -pl :app, which is also where the CLI's own .vaadin/vaadin-dev invocations are rooted.

For internal use only. May be renamed or removed in a future release.

  • Constructor Details

    • InstallDevCliMojo

      public InstallDevCliMojo()

  • Method Details

    • executeInternal

      protected void executeInternal() throws org.apache.maven.plugin.MojoFailureException
      Description copied from class: FlowModeAbstractMojo
      Perform whatever build-process behavior this Mojo implements.
      This is the main trigger for the Mojo inside the Maven system, and allows the Mojo to communicate errors.
      Specified by:
      executeInternal in class FlowModeAbstractMojo
      Throws:
      org.apache.maven.plugin.MojoFailureException - if an expected problem (such as a compilation failure) occurs. Throwing this exception causes a "BUILD FAILURE" message to be displayed.