News, tips, partners, and perspectives for the Oracle Solaris operating system

DevOps Hands on Lab - Installing Netbeans on Oracle Solaris

Here's Part 4, the final part of our series on this year's Hands on Lab on setting up a simple DevOps toolchain on Oracle Solaris. In the previous Part 1, Part 2, and Part 3 we respectively showed how to install and set up Oracle Weblogic Server, Maven, the Oracle Maven WebLogic plugin, Git, and Jenkins in Solaris Zones to create the following toolchain:

The only thing missing from our install is the install of NetBeans or some Integrated Development Environment (IDE) like that. Generally this would actually be on a developer's laptop or workstation so they can work when and where they want, but for this example we'll show how to install and connect NetBeans in the Global Zone of the VirtualBox guest we've been using up to now. This way things are nice and contained for our example even though it's now what you'd normally to.

This blog assumes you're working in the environment we've already set up in the previous parts, if not it should be fairly easy to understand how to use this in a generic case. Of course you could use another IDE if you favor that more

The steps up to now have been focused on creating the automated toolchain on the build server and the deployment server and we've used an archetype as a sample application to test if things are working correctly. Now we only need to install the IDE, install Git, and then pull in the git repository with a clone operation. This will allow us to make some modifications to the code in the application and then test the full toolchain by committing the changes and pushing it up to the origin repository.

1. Installing NetBeans

NetBeans is a very popular open source IDE that supports development in a whole range of different languages but in it's origin lies in development for Java applications and is also written in Java. So like Jenkins and Maven this makes NetBeans very portable and easy to run on practically any operating system. The only thing we will need if first install Java 8 and then we can download and run it.

Because we will need Git too we can install both Java 8 and Git in one action, so as user root in the Global Zone run:

root@solaris:~# pkg install jdk-8 git

As a side note if you've installed Oracle Solaris but are not running the Gnome desktop environment yet, it's very easy to install it. Install the meta package solaris-desktop and reboot the OS.

root@solaris:~# pkg install solaris-desktop

At this point we can choose to either run NetBeans as root or as the user you created when you first installed Oracle Solaris in the first Part of this series. This was necessary because by default Oracle Solaris doesn't allow you to log in as root, you can only assume the root role (with su -) once you're logged in. In my case in VirtualBox I created a user demo and I'll use this user to install and run NetBeans from.

Once you're the user you want navigate to the NetBeans download page and select the Java EE version. Also making sure that you choose the OS independent version (on the top right of the page). You can use the Firefox browser to download it but in my case I'm getting the zip file with wget:

demo@solaris:~$ cd Downloads/
demo@solaris:~/Downloads$ wget http://download.netbeans.org/netbeans/8.2/final/zip/netbeans-8.2-201609300101-javaee.zip
demo@solaris:~/Downloads$ unzip -q netbeans-8.2-201609300101-javaee.zip

At this point you can run NetBeans:

demo@solaris:~/Downloads$ ./netbeans/bin/netbeans

2. Cloning the Repository

Once NetBeans has started we need to create a clone of the Git repository. We do this by going to Team -> Git -> Clone:

Which will ask the location of the repository. The location of the Git repository is in the j-m_zone, so use the IP address of the j-m_zone which in my case is And I fill in "ssh://" as the URL, "git-user" as the username and the corresponding password. Note you can choose to have NetBeans save the password if you want. Then click "Next>":

Then click "Next>" again:

And click "Finish" to finalize the clone:

It will pop up a window to ask you if you want to open the project to work with it, so click "Open Project":

Because we don't have all the specific WebLogic Maven plugins installed here yet NetBeans will find this issue and flag it with a pop-up window. We're not going to be building anything here only editing the code so click "Close" to ignore:

3. Making a Change

Now the left panel should show the "basicWebapp" project. Expand the project, locate the "index.xhtml" file and double click on it. This should open it in the right hand panel:

Find the heading again and make another change to it, or change some other part of the text. Once you've done this you're ready to commit the change and push it to the origin. First click Team -> Commit:

This will bring up a commit screen. Fill in the commit message, something like "Testing Netbeans", and click "Commit":

This will complain that you don't have a user set up yet. For now we can just use the default and click "Yes":

Now the change is committed to the local copy of the Git repository we can push the change to the origin repository. We do this by going to Team -> Remote -> Push… :

Click on "Next >":

Click on "Next >" again:

And finally on "Finish":

Now the code changes have been pushed Jenkins will wake up like before and within a few seconds should start building the application again and then push it to WebLogic. Go back to the browser see how Jenkins runs and then verify the newly made changes automatically appear on your webpage.

At this point the full DevOps toolchain is complete and verified to work. Of course this is a fairly simple setup, we didn't add any testing framework like JUnit or did any work on the Maven POM file to make a differentiation between types of deployment phases but now the base framework is in place you can expand on this like on any other framework.

Finally, the beauty of this way of working is that where the application is finally pushed and run can be fully abstracted from the developer, this means they can focus on creating new code and don't have to worry about platform specific things and the operators can focus on choosing the best platform for the application, be it x86 or SPARC, be it Window, Linux, or Solaris.

This ends this series, check in in the future for more content like this.

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.