
 -----
 Usage
 -----
 Stephane Nicoll
 -----
 2014-05-06
 -----

Usage

  The plugin provides several goals to work with a Spring Boot application:

  * <<<repackage>>>: create a jar or war file that is auto-executable. It can replace the regular artifact or can be
    attached to the build lifecyle with a separate <<classifier>>.

  * <<<run>>>: run your Spring Boot application with several options to pass parameters to it.

  * <<<start>>> and <<<stop>>>: integrate your Spring Boot application to the <<<integration-test>>> phase so that
   the application starts before it.

   []

  Each goal is further described below.

* Repackaging an application

  In order to repackage your application, you simply need to add a reference to the
  plugin in your <<<pom.xml>>>:

---
<build>
  ...
  <plugins>
    ...
    <plugin>
      <groupId>${project.groupId}</groupId>
      <artifactId>${project.artifactId}</artifactId>
      <version>${project.version}</version>
      <executions>
        <execution>
          <goals>
            <goal>repackage</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
    ...
  </plugins>
  ...
</build>
---

  The example above repackages a jar or war that is built during the package phase of the Maven lifecycle,
  including any <<<provided>>> dependencies that are defined in the project. If some of these dependencies
  need to be excluded, you can use one of the exclude options,
  see {{{./examples/exclude-dependency.html}Exclude a dependency}} for more details.

  The original (i.e. non exectuable) artifact is renamed to <<<.original>>> by default but it is also
  possible to keep the original artifact using a custom classifier.

  The plugin rewrites your manifest, and in particular it manages the <<Main-Class>> and <<Start-Class>>
  entries, so if the defaults don't work you have to configure those there (not in the jar plugin). The
  <<Main-Class>> in the manifest is actually controlled by the <<layout>> property of the boot plugin, e.g.

---
<build>
  ...
  <plugins>
    ...
    <plugin>
      <groupId>${project.groupId}</groupId>
      <artifactId>${project.artifactId}</artifactId>
      <version>${project.version}</version>
      <configuration>
        <mainClass>${start-class}</mainClass>
        <layout>ZIP</layout>
      </configuration>
      <executions>
        <execution>
          <goals>
            <goal>repackage</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
    ...
  </plugins>
  ...
</build>
---

  The layout property defaults to a guess based on the archive type (jar or war). For the
  <<<PropertiesLauncher>>> the layout is <<<ZIP>>> (even though the output might be a jar file).

  For more detailed examples of how to configure this goal see:

    * {{{./examples/repackage-classifier.html}Custom repackage classifier}}

    * {{{./examples/exclude-dependency.html}Exclude a dependency}}

	[]

* Running the application

  The plugin includes a run goal which can be used to launch your application from the command
  line:

---
mvn spring-boot:run
---

  By default the application is executed directly from the Maven JVM. If you need to run
  in a forked process you can use the 'fork' option. Forking will also occur if the
  'jvmArguments' or 'agent' options are specified.

  If you need to specify some JVM arguments (i.e. for debugging purposes), you can use
  the <<<jvmArguments>>> parameter, see {{{./examples/run-debug.html}Debug the application}}
  for more details.

  By default, any <<src/main/resources>> folder will be added to the application classpath
  when you run the application and any duplicate found in <<target/classes>> will be
  removed. This allows hot refreshing of resources which can be very  useful when developing
  web applications. For example, you can work on HTML, CSS or JavaScipt files and see your
  changes immediately without recompiling your application. It is also a helpful way of
  allowing your front end developers to work without needing to download and install a Java IDE.

  Of course, if your resources are using tokens that are filtered by Maven, you may want
  to disable that feature as follows:

---
<build>
  ...
  <plugins>
    ...
    <plugin>
      <groupId>${project.groupId}</groupId>
      <artifactId>${project.artifactId}</artifactId>
      <version>${project.version}</version>
      <configuration>
        <addResources>false</addResources>
      </configuration>
    </plugin>
    ...
  </plugins>
  ...
</build>
---

  In order to be consistent with the <<<repackage>>> goal, the <<<run>>> goal builds the classpath
  in such a way that any dependency that is excluded in the plugin's configuration gets excluded
  from the classpath as well. See {{{./examples/exclude-dependency.html}Exclude a dependency}} for
  more details.

  Sometimes it is useful to include test dependencies when running the application. For example,
  if you want to run your application in a test mode that uses stub classes. If you wish to do this,
  you can set the <<<useTestClasspath>>> parameter to true. Note that this is only applied when you
  run an application: the <<<repackage>>> goal will not add test dependencies to the resulting JAR/WAR.

* Working with integration tests

  While you may start your Spring Boot application very easily from your test (or test suite) itself,
  it may be desirable to handle that in the build itself. To make sure that the lifecycle of you Spring
  Boot application is properly managed <around> your integration tests, you can use the <<<start>>> and
  <<<stop>>> goals as desribed below:

---
<build>
  ...
  <plugins>
    ...
    <plugin>
      <groupId>${project.groupId}</groupId>
      <artifactId>${project.artifactId}</artifactId>
      <version>${project.version}</version>
      <executions>
        <execution>
          <id>pre-integration-test</id>
          <goals>
            <goal>start</goal>
          </goals>
        </execution>
        <execution>
          <id>post-integration-test</id>
          <goals>
            <goal>stop</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
    ...
  </plugins>
  ...
</build>
---

  Such setup can now use the {{{http://maven.apache.org/surefire/maven-failsafe-plugin/}failsafe-plugin}} to
  run your integration tests as you would expect.

  For more detailed examples of how to configure this goal see:

    * {{{./examples/it-random-port.html}Random port for integration tests}}

    []
