SOA Suite 12c introduces Maven support to build and deploy artifacts. Oracle has provided extensive documentation on this. Also there already are plenty of blog posts describing how to do this. I will not repeat those posts (only shortly describe the steps). What I couldn’t find quickly enough though was how to deploy artifacts from an artifact repository to an environment. This is a task often done by provisioning software such as Puppet or Jenkins. Sometimes though you want to do this from a command-line. In this post I’ll briefly describe steps required to get your Continuous Delivery efforts going and how to deploy an artifact from the Nexus repository to a SOA Suite runtime environment.

Preparations

In order to allow building and deploying of artifacts without JDeveloper, several steps need to be performed. See the official Oracle documentation on this here: http://docs.oracle.com/middleware/1213/soasuite/develop-soa/soa-maven-deployment.htm#SOASE88425.

Preparing your artifact repository

Optional but highly recommended

• install and configure an artifact repository (Nexus and Artifactory are both popular. For Nexus see: http://books.sonatype.com/nexus-book/reference/install.html)
• configure your settings.xml file in your .m2 folder in order provide information about your artifact repository (for a default Nexus installation described here)

Required

• install the Oracle Maven Sync plugin (Oracle manual 48.2.1)

Below steps are described on the blog of Edwin Biemond: http://biemond.blogspot.nl/2014/06/maven-support-for-1213-service-bus-soa.html

• use the Oracle Maven Sync plugin to put libraries required for the build/deploy process in your local Maven repository
• (if using an artifact repository) put the Oracle Maven Sync plugin in your artifact repository and use it to add the required Oracle libraries

Preparing your project

Referring to the competition here, but Roger Goossens has done a good job at describing what needs to be done: http://blog.whitehorses.nl/2014/10/13/fusion-middleware-12c-embracing-the-power-of-maven/. Mind here though that the serverUrl is provided as a hardcoded part of the sar-common pom.xml. You can of course override this by providing it to Maven in the command-line. If you like it to always be provided command-line (to avoid accidentally not overriding it), don’t add it to the sar-common pom.xml.

• make sure your project can find your MDS (update the appHome and oracleHome properties in your pom.xml)
• create a jndi.properties file (you will want to replace properties in this file during your build process)
• update the composite.revision property

Now you can compile and deploy your project to Nexus and to a runtime SOA environment. During the next steps, I’ll use a test project already deployed to Nexus (a simple HelloWorld SCA composite).

Deploy from Nexus

The repository is prepared. Your project is prepared. You can deploy to an environment from your local directory. You can deploy to Nexus from your local directory. However, during your build process, you don’t want to build and deploy from your source directory / version control, but you want to deploy from your artifact repository. How do you do that? Usually a provisioning tool does this, but such a tool is not always available at a customer or their process does not allow using such tools. We can fall back to the command-line for this.

Get the SAR

During the next step, we start deploying. Because the sarLocation parameter used during deployment cannot be an URL, you have to download your SAR manually first by using the repository API. For Nexus several options are described here and a sample is provided below.

wget http://localhost:8081/nexus/service/local/repositories/snapshots/content/nl/amis/smeetsm/HelloWorld/1.0-SNAPSHOT/HelloWorld-1.0-20150314.150901-1.jar

You can also use curl instead of wget if you prefer. wget and curl are Linux tools. PowerShell 3.0 (Windows 7+) also can use its own variant of wget.

Deploy the SAR

I created a dummy pom.xml file which did nothing but avoid complaining from Maven..

<!--?xml version="1.0" encoding="UTF-8"?-->
4.0.0
nl.amis.smeetsm
DeployApp
1.0-SNAPSHOT

Now you can deploy your downloaded SAR:

[maarten@localhost mvntest]$ mvn com.oracle.soa.plugin:oracle-soa-plugin:deploy -DsarLocation=HelloWorld-1.0-20150314.150901-1.jar -Duser=weblogic -Dpassword=Welcome01 -DserverURL=http://localhost:7101
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building DeployApp 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- oracle-soa-plugin:12.1.3-0-0:deploy (default-cli) @ DeployApp ---
[INFO] ------------------------------------------------------------------------
[INFO] ORACLE SOA MAVEN PLUGIN - DEPLOY COMPOSITE
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] setting user/password..., user=weblogic
Processing sar=HelloWorld-1.0-20150314.150901-1.jar
Adding shared data file - /home/maarten/jdeveloper/mywork/mvntest/HelloWorld-1.0-20150314.150901-1.jar
INFO: Creating HTTP connection to host:localhost, port:7101
INFO: Received HTTP response from the server, response code=200
Deploying composite success.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.479s
[INFO] Finished at: Sun Mar 15 16:09:24 CET 2015
[INFO] Final Memory: 14M/218M
[INFO] ------------------------------------------------------------------------

At first I thought that fetching the project pom.xml file would be required and that this pom.xml could be used for deployment. This did not work for me since the plugin expects to find the SAR file in the target directory (even when I override this).

[maarten@localhost mvntest]$ mvn -f HelloWorld-1.0-20150314.150901-1.pom com.oracle.soa.plugin:oracle-soa-plugin:deploy -DsarLocation=./HelloWorld-1.0-20150314.150901-1.jar -Duser=weblogic -Dpassword=Welcome01 -DserverURL=http://localhost:7101
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building HelloWorld 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- oracle-soa-plugin:12.1.3-0-0:deploy (default-cli) @ HelloWorld ---
[INFO] ------------------------------------------------------------------------
[INFO] ORACLE SOA MAVEN PLUGIN - DEPLOY COMPOSITE
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] setting user/password..., user=weblogic
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.007s
[INFO] Finished at: Sun Mar 15 16:04:03 CET 2015
[INFO] Final Memory: 15M/218M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.oracle.soa.plugin:oracle-soa-plugin:12.1.3-0-0:deploy (default-cli) on project HelloWorld: file not found: /home/maarten/jdeveloper/mywork/mvntest/target/sca_HelloWorld_rev1.0-SNAPSHOT.jar -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

Conclusion

Oracle has done a very nice job at providing Maven support for SOA Suite composites in SOA Suite 12c. The documentation provides a good start and several blog posts are already available for filling your artifact repository with Service Bus and SCA composite projects. In this blog post I have described how you can deploy your composite from your artifact repository to an environment using the command-line.

Of course a provisioning tool is preferable, but when such a tool is not available or the tool does not have sufficient Maven support, you can use the method described in this post as an alternative. This can of course also be used if you want to create a command-line only release for the operations department. If you want to provide a complete command-line installation though without requirements for settings.xml configuration to find the repository (in order to allow usage of the oracle-soa-plugin) you need to provide a separate Maven installation with settings.xml in your release. If the installation is performed from a location which cannot reach your artifact repository, you need to provide the repository as part of your release. These are workarounds though.