MyST: Provision FMW domain with System Artifacts using Maven – part 1

Not all OFMW domains we encounter are as default as others. And when you need to provision a non-vanilla domain with Rubicon Red MyST Studio, these customer-specific customizations can sometimes be hard to fit into your Platform Blueprint or Platform Model.

This post is part of a Series in which Robert Jan de Groot and I explore the inner and hidden parts of Rubicon Red MyST Studio which might come in handy at times.

The case in hand: we need to provision our domain with the addition of a jar-file in the domain/bin folder.
This jar file houses some classes required for start up. This jar is developed in house by the client, and (luckily) is available in the internal Binary Repository Manager (Sonatype Nexus).

MyST Studio has supported something called System Artifacts since ages, and has also introduced proper support for it in the UI since version 6.0.0. With a System Artifact, you can place artifacts on specified locations during provisioning of a Fusion Middleware domain. This page in the documentation lists the currently available types of artifacts which can be used during provisioning.

There are a few prerequisites though:

• Maven needs to be available on the node where the Application Server will live
• The System Artifacts need to be available in your Binary Repository Manager
• Maven needs to know where your Binary Repository Manager lives

Immediately, you’ll spot the issue here: The Oracle System Requirements and Specifications for Fusion Middleware 12c documentation does not list Apache Maven (in any version) as a prerequisite for installing any component of a Fusion Middleware domain.
Here, we’ll present a fully self-contained solution for when your target hosts do not have a fully configured Maven installation available.

How do we do this?

We’ll implement this three step plan:

1. Install Maven
2. Configure Maven
3. Make MyST roll out your artifact

Maven comes with your FMW 12c installation!

Yes, and that also is the trick here.
We need to make MyST think that Maven is installed in the location it by default comes in. There is only one caveat here: you can only use Maven this way when the installation of the products has already happened. This usually is not an issue.

To do this, edit your Platform Blueprint and navigate to Products -> Apache Maven.Set the Configuration Parameter with the name manage-installation to false, and have the Home point to the Maven module in the Oracle Common Home.

In our case, this is:

${[rxr.def.Product-3].home}

Save your Platform Blueprint or Platform Model, or commit it to make the change permanent. You are all set! MyST will now understand the mvn command, which comes in handy for the rest of this article.

Configure Maven with settings.xml

Apache Maven, by default, searches for a settings-file called settings.xml on two locations, we’ll make sure the file will be available in one of them.

To get our own settings.xml in the desired location, we’ll follow this plan:

1. Make settings.xml file in MyST Studio
2. Create Custom Action to put the file somewhere usable
3. Have MyST do this during provisioning of FMW-domain

First off, we’ll need to make the file settings.xml available in MyST Studio.

Create settings.xml

Navigate to Administration -> Custom Actions. Click on ‘Create New’.

Name: settings_xml
Type: Plain Text
Target Location: resources/custom/settings.xml
Description: Settings_xml for Maven
Content:

<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">

  <mirrors>
    <mirror>
      <id>nexus</id>
      <mirrorOf>central</mirrorOf>
      <url>http://nexus.customer.nl/repository/maven-public/</url>
    </mirror>
  </mirrors>

</settings>

Click on ‘Save’, and now we have made the file available for MyST. On all actions done through MyST, this file will be available.
With our previous success under our belt, let’s quickly move on and create a second Custom Action!

Create Custom Action

Name: configure-maven
Type: Jython Action
Description: Put Maven settings.xml on correct location
Content:

import os
def myst(cfg):
  os.system("mkdir -p ~/.m2/ && cp resources/custom/settings.xml ~/.m2/settings.xml")

After clicking on save, this Custom Action will copy the provided settings.xml to the user home directory, in the correct folder for Maven to pick it up and use the contents.
This way, Maven also knows where to look when it will try to resolve artifacts.

Invoke Custom Action when needed

Lastly, we need to have MyST perform this Custom Action when it’s appropriate, which we can achieve by chaining our newly created Custom Action to an action that is already performed by MyST during the regular provisioning of a domain.

This can be done by adding the following to the Global Variables in your Platform Blueprint:

action.create-domain.pre = configure-maven

You’re all done now!
We have successfully performed the following tasks:

• Made the mvn command be available to MyST
• Configured Maven to use our Binary Repository Manager instead of Maven Central over the internet
• Have MyST do the configuring for us

We still need to have MyST roll out our System Artifact, but for that: click here to read part 2.