Skip to Content

The “Neo” Maven Plugin

Developers using the SAP HANA Cloud Platform SDK will know the command line tool called neo. It features 80+ commands to interact with the platform, for instance deploy, start and stop of Java web applications. It can be invoked with a Maven Plugin (see [1]) that has a goal for almost all commands (see [2]).

Usage Example

A practical example that illustrates the usage of the Maven Plugin best is deployment of a Java web application into the cloud. Before we can do that though, you need a SAP HANA Cloud Platform account and the SDK. If you don’t have an account yet, you can sign up for a free developer account (see [3]). The SDK can be downloaded to your machine manually (see [4]), but it can also be automatically installed by the Maven Plugin. Below you can see how to do that:


  <build>

    <plugins>

      <plugin>

        <groupId>com.sap.cloud</groupId>

        <artifactId>neo-java-web-maven-plugin</artifactId>

        <version>1.53.18.2</version>

        <executions>

          <execution>

            <phase>initialize</phase>

            <goals>

              <goal>install-sdk</goal>

            </goals>

            <configuration>

              <sdkInstallPath>${project.build.directory}/sdk</sdkInstallPath>

            </configuration>

          </execution>

        </executions>

      </plugin>

    </plugins>

  </build>

Note: You may also pick neo-javaee6-wp-maven-plugin for the Java EE6 Web Profile runtime. Please refer to the previous blog post to learn more about the group ID, artifact ID, and the versioning scheme/how to select the right version (see [5]).


The above snippet runs the install-sdk goal in the initialize phase and installs it to the given folder (translates to target/sdk). What does that mean? Maven has different life cycles, the most important one being the default life cycle. Such a life cycle has different phases and initialize is a very early such phase. In other words, the above execution installs the SDK early on so that it is available to the following steps in your build script.


Now, let’s deploy a Java web application:


  <build>

    <plugins>

      <plugin>

        <groupId>com.sap.cloud</groupId>

        <artifactId>neo-java-web-maven-plugin</artifactId>

        <version>1.53.18.2</version>

        <executions>

          <execution>

            <phase>install</phase>

            <goals>

              <goal>deploy</goal>

            </goals>

            <configuration>

              <sdkInstallPath>${project.build.directory}/sdk</sdkInstallPath>

              <host>${my.datacenter}</host>

              <user>${my.username}</user>

              <password>${my.password}</password>

              <account>${my.account}</account>

              <application>${my.application}</application>

              <source>${my.war}</source>

            </configuration>

          </execution>

        </executions>

      </plugin>

    </plugins>

  </build>

Tip: To avoid multiple definition of the coordinates for the Maven Plugin (group ID, artifact Id, version) you may instead define them once in the plugin management section of your pom.xml. You may also like to combine both or more executions together to group them.


This snippet is somewhat larger, but it follows the same principles. It runs the deploy goal in the install phase. This time we picked the install phase, because it is a phase rather to the end of the Maven default life cycle at which state your Java web application will have been already compiled, unit-tested, packaged and even integration-tested. Install may be somewhat misleading though, because it means from Maven point of view: installation of the artifacts into an artifact repository to share the build result with others. However, common practice is to “hook” into phases to do your custom build steps and in this case we picked install to deploy the WAR into the cloud, because all the other steps (compile through integration-test) had to be completed to do so. As a side note, you would do that only for a testing instance of the application in the cloud, but not for a productive instance. For that you would use more sophisticated goals and a so-called rolling update procedure.


What we haven’t talked about is the configuration for this goal:

  • sdkInstallPath: Here we tell the Maven Plugin where to find the SDK (installed by the previous snippet).
  • host: This is the domain of the SAP HANA Cloud data center you want to deploy to. There are different data centers around the globe. If you have a free developer account (see [3]) it will be hanatrial.ondemand.com for you.
  • user, password, account: You will get those when you have registered for a free developer account (see [3]) or have purchased one (visit saphana.com for more information). The notation with ${…} refers to Maven properties which are kind of variables/placeholders in Maven speak. This approach is helpful to define repeatedly used configuration only once or inject/overwrite it from outside. Especially the latter is helpful if you like to avoid clear text passwords in your pom.xml.
  • application: The name of the cloud application for which this deployment shall be done.
  • source: This is the path to the Java web application (WAR file) you like to deploy. If it was built within the same project, it will usually be ${project.build.directory}/${project.artifactId}.war.


The documentation of the Maven Plugin can be found online (see [2]). You will find there also information on more complex scenarios, for instance on how to do integration testing with the Maven Plugin or how to work with a proxy.

References

[1] SAP HANA Cloud Platform artifacts on Maven Central

[2] “Neo” Maven Plugin site documentation

[3] Registration for a free developer account for SAP HANA Cloud Platform

[4] SAP HANA Cloud Platform tools download page

[5] Building Java Web Applications with Maven

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

Leave a Reply