Doing more with the WebLogic Maven Plugin (Robot, Selenium and Sonar too!)

The ‘new and improved’ WebLogic Maven Plugin in WebLogic Server 12.1.2 provides a bunch of additional capabilities above and beyond your straight compile/package/deploy operations.  In this post I wanted to take you on a journey of some of these additional capabilities and explore how we might use them to automate testing of a project.

We are going to use a somewhat contrived example of a simple web application, so the capabilities we look at are going to probably look like overkill for the project.  But they probably make a lot more sense for a larger project, and I am sure you can ‘scale up’ the sample and imagine how things would work.

What we are going to do is take an application, and set it up so that our build process does the following:

  • compile the code
  • run unit tests
  • package it into a WAR
  • install WebLogic Server
  • create a simple domain
  • start the Admin Server
  • deploy the application onto the Admin Server
  • run a set of integration tests against the application
  • stop the Admin Server
  • run quality checks on our application

The integration tests and quality checks are not actually going to be done with the WebLogic Maven Plugin directly, but I am including them anyway to make the example a bit more realistic.

Let’s get started by creating a simple web application from the WebLogic Basic Web Application Maven Archetype.  I am assuming that you already have a Maven repository that you have populated with the artifacts from your WebLogic Home.  If you don’t, see this post for details on how to do that.

Note: If you prefer, you can get the project by cloning my ci-samples git repository (git:// and looking at the my-webapp directory.

mvn archetype:generate

Great!  Now let’s set up our POM file to carry out the steps we want. We are going to do this by adding ‘execution’ entries for the weblogic-maven-plugin to our POM’s ‘build’ section.

Here’s what we need to add to the POM to install WebLogic Server.  Let’s assume that we have the installer (wls_121200.jar) available in a well known location on our machine.

<!-- install weblogic -->
    <installCommand>@JAVA_HOME@/bin/java -Xms512m -Xmx1024m -jar @INSTALLER_FILE@ -silent -response ${basedir}/misc/wls_response.txt</installCommand>

So, this will execute the weblogic-maven-plugin:install goal during the pre-integraton-test phase of our build, i.e. after we have compiled and packaged our web app.  We need to tell the weblogic-maven-plugin where to install WebLogic Server (installDir), where the installer is (artifactLocation) and since we are using the JAR installer, we need to give it the installCommand as well, to tell it how we want WebLogic Server installed.  If we use the ZIP installer, we don’t need to give it installCommand – it knows how to install from the ZIP installer.

In this example we are using a silent install with a response file. Here are the contents of the response file – note that it has the ORACLE_HOME in it:


Response File Version=


#The oracle home location. This can be an existing Oracle Home or a new Oracle Home

#Set this variable value to the Installation Type selected. e.g. WebLogic Server, Coherence, Complete with Examples.
INSTALL_TYPE=Complete with Examples

#Provide the My Oracle Support Username. If you wish to ignore Oracle Configuration Manager configuration provide empty string for user name.

#Provide the My Oracle Support Password

#Set this to true if you wish to decline the security updates. Setting this to true and providing empty string for My Oracle Support username will ignore the Oracle Configuration Manager configuration

#Set this to true if My Oracle Support Password is specified

#Provide the Proxy Host

#Provide the Proxy Port

#Provide the Proxy Username

#Provide the Proxy Password

#Type String (URL format) Indicates the OCM Repeater URL which should be of the format [scheme[Http/Https]]://[repeater host]:[repeater port]

This will get WebLogic Server installed for us.  The next thing we want to do is create a domain.  The weblogic-maven-plugin:create-domain goal will create a ‘simple’ domain for us.  If you want to create a more complex domain, you should use the wlst goal and write a WLST script to create the domain.

For the simple domain, all we need to tell it is where WebLogic Server is installed (middlewareHome), where we want the domain (domainHome) and the administration user and password for the new domain.

Again, we have this execute in the pre-integration-test phase.  When there are multiple executions in the same phase like this, Maven will execute them in the order they appear in the POM file, so we place this one after the install execution.

<!-- Create a domain -->

Now we need to start up our server, we can do this using the weblogic-maven-plugin:start-server goal and passing in the domainHome:

<!-- start a server -->

Now we have a running server, we are ready to deploy our application. We do this using the weblogic-maven-plugin:deploy goal.  We need to give it the server details (it defaults to http://localhost:7001, so that will work for us) and the location of the application we want to deploy (source).

<!--Deploy the application to the server-->
    <!--The admin URL where the app is deployed. Here use the plugin's default value t3://localhost:7001-->
    <!--The location of the file or directory to be deployed-->
    <!--The target servers where the application is deployed. Here use the plugin's default value AdminServer-->

Once we have our application deployed, we are ready to run our integration tests.  Those would run in the integration-test phase, but let’s come back to them in a moment.

First, let’s handle the server shutdown.  We will do this in the post-integration-test phase, after all of our tests have run.  We can use the weblogic-maven-plugin:stop-server goal to shut down the server.  We need to tell it the domainHome and the server details:

<!-- stop the server -->

Ok, so now we have most of our steps implemented, but to make this more useful and realistic, let’s add some integration tests and quailty checking to the project.  We are going to use Robot Framework and Selenium for the integration tests, and Sonar with PMD for the quality checks.

If you are not familiar with Robot Framework, you might like to read over this earlier post.

To add Robot Framework to our project, we just need to add a dependency and an execution to our POM.  Here is what we need:


We will also need to create the directories to store our test cases and libraries.  We need the following:

project root
- src
  - test
    - robotframework
      - acceptance
    - resources
      - robotframework
        - libraries

We want to use the Selenium2Library.  Here is the dependency to add to your POM to get this library and the necessary dependencies:


Now we are ready to write our test cases.  We will keep these in the acceptance directory.  To keep things simple, we will just write one test case that will open our application and enter some data into the form, press the button and check the output.

Here is what we need:

*** Settings ***
Library  Selenium2Library

*** Test Cases ***
Quick Test
   Open Browser                        http://localhost:7001/basicWebapp/index.xhtml
   Page Should Contain                 Please Enter Your Account Name and Amount
   Page Should Contain Textfield       j_idt10:name
   Page Should Contain Textfield       j_idt10:amount
   Page Should Contain Button	       j_idt10:j_idt18
   Input Text  	       	               j_idt10:name             Bob
   Input Text                          j_idt10:amount           25.00
   Click Button	                       j_idt10:j_idt18
   Wait Until Page Contains            The money have been deposited to Bob, the balance of the account is 25.0
   Close Browser

Now for testing the code quality.  We will use Sonar for that.  You can download the community edition from here.

Once you have that downloaded, just unzip it, and then go start it up with this command (adjust for your OS):


You can access the console at http://localhost:9000

To run sonar on our project, you can just specify the sonar:sonar goal on the command line.  So to run the whole thing, we do the following:

mvn verify sonar:sonar

Now you can sit back and watch as WebLogic Server is installed, the domain is created, our application is built and deployed, tested, and checked for quality.

At the end of all this, we can look at the test report, which is located in target/robotframework-reports/report.html (open it with your browser).


You can click on the Quick Test link to see details of the test.


And to check our quality, go to the sonar console (refresh it if you had it open already) and click on our project (my-webapp) to see details.  You will see there are two major problems.  Click on the Major link to see them.  Then click on the AccountBean to see the problems in the context of the actual code.

Here you can see we are using an implementation type HashMap when we should have been using an interface (Map).


Obviously, this is a very trivial example, but hopefully you get the idea, and see what you could do with a much larger code base!

About Mark Nelson

Mark Nelson is a Developer Evangelist at Oracle, focusing on microservices and messaging. Before this role, Mark was an Architect in the Enterprise Cloud-Native Java Team, the Verrazzano Enterprise Container Platform project, worked on Wercker, WebLogic and was a senior member of the A-Team since 2010, and worked in Sales Consulting at Oracle since 2006 and various roles at IBM since 1994.
This entry was posted in Uncategorized and tagged , , , , , , , . Bookmark the permalink.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s