The Integration blog covers the latest in product updates, best practices, customer stories, and more.

  • October 1, 2015

SOACS plus DevCS - Chapter 08

In this series of posts and videos, we will explore creating and deploying a SOA composite using Oracle Developer Cloud Service.

< Previous Chapter | Next Chapter >

Chapter 08 - Deploying to On-Premise Server

BIG WARNING: As mentioned in a previous chapter, JDeveloper defaults the revision to "1.0" whereas Maven expects the revision to "1.0-SNAPSHOT". To work seamlessly across both, for each project, you should change the "revision" in composite.xml:

<composite name="MyComposite" revision="1.0-SNAPSHOT" ...>

and the "composite.revision" in pom.xml:


While Maven has a "deploy" lifecycle phase, it unfortunately does not pertain to any sort of deployment of the artifact that you would likely care about. The Maven concept of deploy involves pushing your artifact jar/war/ear/etc into a remote Maven repository so that others can see and use it. While this is itself an important event, you would think they could have come up with a word that is not already over-used and overloaded by countless other products.

So, if Maven has a "deploy" lifecycle that has nothing to do with the ops kind of deploy, then how do you deploy to a web server? Most vendors provide a specific goal (usually called "deploy") in their plugin that is specifically designed to talk to their product. Often times, this goal is invoked manually. The Oracle plugin ties the "deploy" goal of its plugin to the "pre-integration-test" Maven lifecycle phase. This ensures the composite is available during the "integration-test" Maven lifecycle phase. This is sort of a no-brainer since integration tests almost necessarily require the artifact to be running in its native environment (e.g., usually an application container) but it is not without some problems: Since the "install" phase runs the "pre-integration-test" phase, this means you cannot easily push the built artifact into your local Maven repository without first deploying it to a running server. In a future chapter, we will see how we can disable this out-of-the-box deploy behavior.

To summarize: to deploy your composite, you can use the "pre-integration-test" lifecycle phase, the "integration-test" phase, or you can call the "deploy" goal of the Oracle SOA Maven plugin directly (in a future chapter we will also explore associating the SOA plugin with a prefix to simplify typing):

mvn pre-integration-test

mvn integration-test

mvn com.oracle.soa.plugin:oracle-soa-plugin:deploy

While Linux is used in the video series, all mvn and git commands are applicable to Windows.  Any variations will be called out in the accompanying blog.

Helpful links:

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.