Package com.vaadin.flow.devloop.mavenext

Class DevLoopBuildExtension

java.lang.Object
org.apache.maven.AbstractMavenLifecycleParticipant
com.vaadin.flow.devloop.mavenext.DevLoopBuildExtension
public class DevLoopBuildExtension extends org.apache.maven.AbstractMavenLifecycleParticipant
Overrides the server plugin's configuration for the run the dev loop drives, without touching the project's pom.

Maven gives a <configuration> value in the pom precedence over the user property the same parameter exposes, so -Djetty.scan=0 on the command line does nothing to a project that writes <scan>2</scan>, which a generated WAR starter does by default. The plugin then redeploys the webapp on a schedule of its own, the second driver of what the transaction model owns: measured, one apply that reported a clean hot swap was followed by the plugin tearing the context down and rebuilding it, losing every page's state for a change that was already live.

Asking every project to write <scan>0</scan> is not a fix - it is a requirement on humans and agents that a tool should not need. A build extension is the supported way to change a model the daemon does not own: it runs inside the application's own build, before any mojo, and edits the effective plugin configuration in memory. Nothing is written to the project.

This class lives in the daemon's jar because that jar's path is the one thing the daemon always knows - it is already its own -javaagent - so putting the extension anywhere else would mean a second artifact to resolve and keep in step. It is compiled against Maven's API at provided scope and is never loaded in the daemon's own JVM; only Maven ever sees it.

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

  • Field Summary

    Fields
    Modifier and Type
    Field
    Description
    static final String
    FORCE_PROPERTY
    What to force on it, as element=value pairs separated by semicolons.
    static final String
    MODEL_FILE
    Where each module's effective model is left, relative to the module's own directory.
    static final String
    PLUGIN_PROPERTY
    groupId:artifactId of the plugin to reconfigure.

  • Constructor Summary

    Constructors
    Constructor
    Description
    DevLoopBuildExtension()
     

  • Method Summary

    Modifier and Type
    Method
    Description
    void
    afterProjectsRead(org.apache.maven.execution.MavenSession session)
     

    Methods inherited from class org.apache.maven.AbstractMavenLifecycleParticipant

    afterSessionEnd, afterSessionStart

    Methods inherited from class java.lang.Object

    clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

  • Field Details

    • PLUGIN_PROPERTY

      public static final String PLUGIN_PROPERTY
      groupId:artifactId of the plugin to reconfigure.
      See Also:

    • FORCE_PROPERTY

      public static final String FORCE_PROPERTY
      What to force on it, as element=value pairs separated by semicolons. Passed rather than hard-coded so that the values stay in ServerPlugin, where the rest of a server's description lives, and a second container needs no change here.
      See Also:

    • MODEL_FILE

      public static final String MODEL_FILE
      Where each module's effective model is left, relative to the module's own directory.

      The daemon reads poms with the JDK's XML parser and no Maven at all, which settles most questions but not the two Maven alone can answer: which profiles are active, and what a module inherits from a parent outside the checkout. Both are already decided by the time this runs, so writing them down costs nothing and saves the daemon from guessing.

      Relative to the module and not to ${project.build.directory}, deliberately: the reader is the daemon, which has no Maven to ask where that directory points, so a project that moves it - <build><directory>build</directory></build> - would have the two ends looking at different paths and the model would read as simply missing. target/devloop/ is where the daemon keeps everything else it writes per module, and it is the same path on the reading side; see EffectiveModel#FILE.

      See Also:

  • Constructor Details

    • DevLoopBuildExtension

      public DevLoopBuildExtension()

  • Method Details

    • afterProjectsRead

      public void afterProjectsRead(org.apache.maven.execution.MavenSession session)
      Overrides:
      afterProjectsRead in class org.apache.maven.AbstractMavenLifecycleParticipant