Uploaded image for project: 'WildFly Maven Plugin'
  1. WildFly Maven Plugin
  2. WFMP-59

Add official support for launching and configuring a dev/test WildFly server outside of builds

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Obsolete
    • Icon: Major Major
    • None
    • 1.1.0.Alpha11
    • Maven Plugin
    • None

      I think this is a gap in the Maven plugin's current feature set that, if plugged, would provide a lot of benefit to folks...

      It'd be great if the WildFly plugin had something analogous to cargo:run that would also allow folks to run some management commands and reload the server before deploying the specified artifact. The workflow would be something like this:

      1. Developer would like to either A) manually poke at their WildFly-hosted application in a local browser, or B) run their integration tests against their WildFly-hosted application from their IDE.
      2. Developer uses their IDE or the command line to run mvn wildfly:awesome-goal. This kicks off the following:
        1. The WildFly plugin downloads and starts up the specified version of WildFly and waits for it to be available.
        2. The WildFly plugin runs the commands or script that are specified in the dev's project's POM that are needed to properly configure things for the application (e.g. setup data sources, configure SSL, change ports, etc.).
        3. The WildFly server is reloaded to ensure that all of those changes are applied.
        4. The WildFly server deploys the application artifact(s) that are specified in the dev's project's POM.
        5. The WildFly plugin waits for the application(s) to start up.
        6. The WildFly plugin happily hums along running the server, and waits there indefinitely.
      3. The dev does whatever they needed to do (e.g. debug some of their test cases in their IDE).
      4. All done now, the dev stops the WildFly plugin from their IDE or presses ctrl+c , at which time it will cleanly shutdown the server and exit itself.

      I'd expect a POM configuration something along these lines:

      <project>
          ...
          <artifactId>some-project-whose-tests-require-wildfly</artifactId>
          ...
          <build>
              ...
              <plugins>
                  ...
                  <plugin>
                      <groupId>org.wildfly.plugins</groupId>
                      <artifactId>wildfly-maven-plugin</artifactId>
                      <version>1.awesome</version>
                      <configuration>
                          <preDeployCommands>
                              <preDeployCommand>...</preDeployCommand>
                          </preDeployCommands>
                          <reloadBeforeDeploy>true</reloadBeforeDeploy>
                          <deployArtifacts>
                              <deployArtifact>
                                 <groupId>...</groupId> ...
                              </deployArtifact>
                          </deployArtifacts>
                      </configuration>
                  </plugin>
                  ...
              </plugins>
              ...
          </build>
      ...
      </project>
      

      Does that make sense? I do this all the time with Jetty, using the cargo:run goal for it. I suspect that the wildfly:run goal was designed for this purpose, but it appears that it doesn't officially support running commands/scripts, and definitely doesn't have any supported mechanism to cleanly reload things after that. Given how much container customization most of the EE apps that WildFly is used to host require, this seems like something that many/most plugin users would benefit from.

            Unassigned Unassigned
            karlmdavisgov Karl Davis (Inactive)
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: