In this series of posts and videos, we will explore creating and deploying a SOA composite using Oracle Developer Cloud Service.
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:
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.