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

  • October 16, 2015

SOACS plus DevCS - Chapter 13

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 13 - Building and Deploying Using Hudson

Finally, part of the whole reason you are here: building your artifacts on the cloud. To begin, we again need the repository information. In the previous chapter, I put the repository information in settings.xml. This was partly done for simplicity. The introduction of Hudson to this process makes this route more difficult. Normally, Hudson allows you to upload a number of settings.xml to be used by the builds. DevCS does not fully support this, however. The alternative is to pass in "-s path/to/settings.xml" in the text field that is reserved for the goals you wish to run. Since Hudson just concatenates that whole string to generate a command line, this works, but it is not the best way (granted it seems to be the only way, though).

The alternative I chose for this chapter was to put the repository information in the project pom.xml. I think this is reasonable practice. It allows new team members to clone your repository and know exactly where Maven will download the dependencies. They simply must provide a username and password in their own settings.xml. But "Wait!", you say, "if a developer needs a username/password in settings.xml then how does Hudson connect?". The Hudson running within DevCS has a pre-established trust with the Maven repository. So, all that is necessary for Hudson is for you to point it to the Maven repository (the builds generated by DevCS's Hudson do not automatically add the project's Maven repository).

In case you lost track: to summarize, I am moving the repository element we used in the previous chapter from settings.xml to the project's pom.xml. The server element should should always be in settings.xml as this is a per-user configuration element. Again, the important thing to remember is that the child "id" element of the "repository" element must match the "id" element of the "server" element; otherwise, you will likely get "permission denied" errors.

If you want to run the unit tests on the composite, you must also uncomment the reference to jndi.properties in the project's pom.xml and create a jndi.properties file that contains the server you want to run the tests against. This is shown at 0:37 of the video.

Finally, we put everything together in a Hudson build. The contents are too much to put in text here. A sample build file is shown at 1:10 of the video.

While the above works, it has many weaknesses:

  1. If the repository element is put in the pom.xml, you have to include it in each project's pom.xml. It is not sufficient to put it in the aggregator pom.xml. This leads to a high level of duplication.
  2. We can further generalize the above point to say that each SOA project pom.xml contains a high level of duplications. Almost all the properties are the same for all projects in the application.
  3. There is an implicit dependency between the jndi.properties in source control and the Hudson build configuration; specifically, the server name, user name, and password. Implicit dependencies are a cardinal sin as far as maintainability is concerned.

Because of these weaknesses, I have created a more consolidated template that can be used for multi-composite applications that reduces redundancy, improves usability, and enhances functionality. This template will be used in a future chapter, so I recommend holding off on judgements before reading that chapter.

Helpful links:

Join the discussion

Comments ( 2 )
  • James Calise Monday, November 9, 2015

    Great detail, and very helpful! I have followed all the steps, however my maven deploy from Hudson builder in DevCS fails with a response code=-1. It seems that there Is some networking issue between DevCS and SOACS, did you have to do anything additional to enable the deploy?

  • David.-Oracle Monday, November 9, 2015

    Hi James,

    Thank you for your support. I have a few other videos that I have not published yet. One of them is deploying to SOACS. While there are a few complications around deploying to SOACS, these are primarily SSL related and are common issues related using self-signed certificates. I cannot think of any tricks if deploying using non-SSL.

    1) Make sure you can deploy from local box. This ensures the ip and port are correct.

    2) If #1 works on local box, then make sure the proxy information is correct in your Maven build step. Notice in the video how I pass in "http.proxyHost" in the properties section. Your proxy host may be (most likely is) different than mine. You can retrieve the proxy information in your DevCS by running "cat ~/.m2/settings.xml" as a script build step in Hudson.

    Let me know how it works out.

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