Sunday, January 12, 2014

Fedora 20 Developer Workstation Configuration

My hard drive crashed and I decided to switch back to fedora after using other distributions for the past few years. I'm going to document the packages I install and the customization and configurations I made to create my workstation. I primarily use my workstation for software development but also use it to listen to music, watch videos, etc. so much of what I do may be applicable to other types of users as well.

My Instructions assume 64-bit fedora 20.

Disable SELinux

SELinux always seems to cause one problem or another and so I usually just disable it. Edit /etc/selinux/config and change the line:




Install Miscellaneous Utilities

gnome-tweak-tool is used to make some modification to the gnome desktop. Install it with the following command:

yum install gnome-tweak-tool

Unison is a tool I like for synchronizing files between different workstations. I use it as a simple backup tool and to keep documentation and downloads synchronized between my workstations. Install it with the following command:

yum install unison

Some other goodies:

yum install git nmap wget

Install Chrome

To install chrome (stable and 64-bit version), we need to add a repository by creating the file:


with the following contents:


Install the stable version of chrome with the following command:

yum install google-chrome-stable

Add RPM Fusion and Livna Repositories

Fedora is very strict about only offering open source software. Some useful software that is not open source is still available to be installed and much of it is available in the RPM Fusing and Livan repositories. We will add these two repositories with the following commands:

yum localinstall --nogpgcheck

yum localinstall --nogpgcheck

rpm -ivh

rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-livna

Install Multimedia Applications and Codecs

Install codecs for listening to music and watching videos with the following command:

yum install gstreamer gstreamer-plugins-good gstreamer-plugins-bad gstreamer-plugins-ugly gstreamer-plugins-bad-nonfree ffmpeg ffmpeg-libs gstreamer-ffmpeg libdvdread libdvdnav lsdvd libdvdcss vlc audacity

Install Flash

In case you want/need flash, install with the following commands:

rpm -ivh

rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-adobe-linux

yum install flash-plugin

Install Graphics Applications

Install various graphics applications for working with images with the following command:

yum install gimp gimp-data-extras gimpfx-foundry gimp-lqr-plugin gimp-resynthesizer gnome-xcf-thumbnailer ImageMagick nautilus-image-converter inkscape dia

Install PostgreSQL

Install PostgreSQL with the following command:

yum install postgresql-server postgresql postgresql-contrib postgresql-jdbc pgadmin3

Initialize the PostgreSQL database with the following command:

/bin/postgresql-setup initdb

Now we want to start the service and then enable it to start on reboot with the following commands:

systemctl start postgresql.service
systemctl enable postgresql.service

We can verify that PostgreSQL is started by su'ing to the postgres user and connet to the PostgreSQL database with the following command:


Since we're logged in, we should set a password for the postgres user with the following command at the postgres# prompt:

alter user postgres with passpord 'new_password';

Now we can exit out with the \q command.

We want to configure PostgreSQL so that applications and users can connect to the database on localhost. To do this, we need to modify the file:


and change the line:

host    all             all               ident


host    all             all               md5

After this change, we need to restart PostgreSQL with the following command:

sysemctl restart postgresql.service

We can now connect to the PostgreSQL database with the following command:

psql -U some_user -h localhost some_database

Install OpenLDAP

I actually gave up on this and will go back to using the OpenDS server for now even though this project seems to have gone away when Oracle bought Sun Microsystems. ApacheDS looked like an interesting option until I saw that is wants to pull in 180 dependencies.

Install the OpenLDAP server with the following command:

yum install openldap openldap-clients openldap-servers

Now we want to start the service and then enable it to start on reboot with the following commands:

systemctl start slapd.service
systemctl enable slapd.service

Install Apache

Install the Apache web server with the following command:

yum install httpd httpd-devel httpd-manual mod_ssl

Now we want to start the service and then enable it to start on reboot with the following commands:

systemctl start httpd.service
systemctl enable httpd.service

Configuration varies quite a bit depending on usage and is left as an exercise for the reader...

Install Tomcat

Install the Apache Tomcat application server with the following command:

yum install tomcat tomcat-admin-webapps tomcat-docs-webapp tomcat-javadoc tomcat-webapps tomcat-native

Now we want to start the service and then enable it to start on reboot with the following commands:

systemctl start tomcat.service
systemctl enable tomcat.service

Configuration varies quite a bit depending on usage and is left as an exercise for the reader...

Install VirtualBox

VirtualBox: when you want to try out other distro's or just have to run something in Windows.

yum install VirtualBox

Monday, December 30, 2013

Hudson 3 Essentials eBook (and more) for $5 until January 3rd

You can get my Hudson 3 Essentials eBook and much for only $5 from Packt Publishing's eBook Bonanza.

There are quite a few interesting books to choose from and even some videos. So if you have been curious about some new technology, now would be a good time to stock up on a few good books.

Sunday, December 29, 2013

Grails and GWT

I've been working with the Grails framework and the Groovy language for the past three years. I've recently switched jobs and have begun working with GWT again for the first time since 2008. I've really enjoyed working with Groovy and Grails and it has been one of the most enjoyable and productive technologies I've worked with.

As I'm relearning and transitioning to a GWT project, I want to document the differences I find between the frameworks and each of their pros and cons. I understand that it's a little like comparing apples and orangutans since Grails is a full stack framework and GWT is primarily a web tier framework, but maybe there can be some benefit from the comparison anyway. I also know that I will be biased toward Groovy and Grails since I am more comfortable with that framework, but I'll try and be as impartial as possible.

I will implement the same application in both technologies. The application will be very simple, basically it is just a single page CRUD web application that will manage a book library. The database will have books and authors tables, so we'll have a simple many to many relationship. I would like to use an embedded database in development mode and PostgreSQL when deployed in production.

To try and make the comparison a little more equal, I will add spring (on the server side) and hibernate to the sample GWT project. I will add a JavaScript front-end to the sample Grails project. I'm not sure which JavaScript front-end to add to Grails, I'm thinking either AngularJS or EmberJS (I don't really know either one, just looking for something new to learn).

After this is done and I'm more comfortable with GWT, I would like to look at the Google Web Toolkit for Grails plugin and evaluate the possibility of having a Grails server side and a GWT front end.

Sunday, December 22, 2013

Hudson 3 Essentials Book

I recently finished my first book, "Hudson 3 Essentials" for Packt Publishing. The book description is available here.

The purpose of this post is to describe the book from my perspective.

The book is written as a quick and hands on introduction to Hudson 3 for readers who are new to Hudson or who have very little experience working with Hudson. After finishing the book, readers should understand the basics of Hudson and have the foundation to extend their knowledge with online resources and/or experimentation.

Chapter 1 is a brief introduction to Hudson, Continuous Integration and how using Hudson can help software development teams. This will hopefully give the reader a reason to continue on with the rest of the book.

Chapter 2 shows how to easily run and configure Hudson using common open source application servers as well as in stand-alone mode. I give detailed installation instructions for tomcat, glassfish and JBoss AS. I would have liked to include jetty but I haven't worked with it enough and was running short on time. The reader should have a working Hudson 3 instance by the end of this chapter.

Chapter 3 covers the basics of Hudson usage and configuration including security options. This isn't a very exciting chapter, but necessary. There are a lot of nice options for integrating Hudson with existing infrastructure (LDAP or application server security) or using Hudson itself.

Chapter 4 is about Hudson plugins. We explain the different categories of Hudson plugins and install a couple of the more common plugins. We then introduce writing your own plugin. Writing Hudson plugins could probably take a couple of chapters on their own but this is hopefully enough to get the reader started. It was a pleasant surprise how easy it was to get started with a new plugin. The sample plugin that was created in this chapter is on my github page.

Chapter 5 is where we start creating Hudson jobs. I wasn't too sure how to handle this chapter, then I realized how easy it would be to take an existing open source project and build it in Hudson. I wanted to demo as many technologies as possible (especially projects I like) and create a sample job for each of them. So we create three jobs to demonstrate three technologies:

  1. maven is used to build the Spring Petclinic application
  2. gradle is used to build the gradle project (cute!)
  3. grails is used to build the spring-security-core grails plugin

Finally, we show how you can use groovy to perform tasks that aren't supported by plugins. It's amazing how easy and powerful combining groovy and Hudson in this way is.

Chapter 6 is about how we can use Hudson to run tests on the projects and create reports based on the test results. Hudson leans very heavily on the tests run by the build too (ant, maven or gradle) that is being used and then collecting those results into a central location. We demonstrate creating javadoc from existing code, running and publishing JUnit tests, and running and publishing PMD, FindBugs and Checkstyle tasks. I think this could be very useful for a manager to be able to easily keep tabs on project status without status meetings. A testing team could also have a baseline of tests that could be automated and insist that no build be promoted to the testing environment that didn't pass these automated tests. The sample project that was created for this chapter available on my githup page.

Chapter 7 covers the important topic of backing up your Hudson configuration and also upgrading. I had a bit of fun describing the team feature that was added in Hudson 3.1 by using the Avengers and X-Men as example teams.

That's it. I hope people find the book useful.

Sunday, May 27, 2012

Twitter Bootstrap is great

I just updated a static site I had been working on with code from the Twitter Bootstrap project. I have mostly worked on the server side of web (and pre web) projects and do not have a lot of experience designing web interfaces. I'm impressed with how easy it was for me to very quickly create a static site that was not embarrassing. There is probably much that I could still do to improve the look of the site and I will work on that over time.

So a big thanks to Twitter and the Twitter developers for releasing this tool as open source.

Saturday, April 2, 2011

Grails 1.3.6 and JBossWS work well together

JBossWS may not be the first option that comes to mind when you think of adding SOAP web services to your grails application, but if you are deploying to a JBoss server, this choice works very well and should be considered.

I will describe how to build a PingService using a bottom-up approach. The ping service has one method, greet, which takes a string argument representing a name and returns a friendly greeting.

The example is very simple and the solution is more complicated than it needs to be in order to show how java code (the JBossWS method) can call a Grails Service. In a real world scenario, this would be a suitable approach.

We will begin by creating a Grails Application named demo:

grails create-app demo

Next we will create a Grails Service named PingService:

grails create-service

Despite the name, this class is a grails service (spring bean) and not a web service. This method will be called by the web service.

class PingService {
static transactional = true

String greet(String name) {
"Hello ${name}!"

Create an annotated POJO named Ping in the package of the src/java directory:

@WebService(targetNamespace = "",
serviceName = "PingService")
@SOAPBinding(style = SOAPBinding.Style.RPC)
public class Ping {

Add the annotated greet method:

public String greet(@WebParam(name="name") String name) {

NOTE: the WebResult annotation gives a meaningful name to the return variable in the generated WSDL.

Now the greet method in the JBossWS need to call the Grails PingService. Add the following to the greet method of the JBossWS:

ApplicationContext ctx = (ApplicationContext)ApplicationHolder.getApplication().getMainContext();
PingService service = (PingService)ctx.getBean("pingService");
String greeting = service.greet(name);
return greeting;

This retrieves the spring context from the Grails ApplicationHolder, then the PingService spring bean from the spring context and then finally calls the greet method on the PingService spring bean.

We are done with the coding now, we just need to define the servlet and its mapping in the web.xml. Grails generates the web.xml from a template, so we will need to run the grails install-templates target:

grails install-templates

You will notice a new src/templates directory. You can remove the artifacts and scaffolding folders underneath the templates directory.

Add servlet and servlet mapping to the src/templates/web.xml file:


We can now deploy our Grails application to a JBoss AS configuration.

After you have deployed your web application, you can view the WSDL for your web application at:


and access the web service at:


What we have accomplished is that we have mixed the conveniences of JBossWS and JBoss AS with the conveniences of the Groovy language and the Grails framework and have quickly created a web service. This example also shows how well Groovy and Grails work in the Java world.

The disadvantage of this approach is that when we run the application from our IDE, we will not be able to test our web services because of our dependency on the JBossAS to generate our web services. We can get around this by just using/testing the web services by calling the grails service methods when running in development mode.

Sunday, November 28, 2010

How to Deploy a grails 1.3.5 webapp to JBoss 5.1.0.GA

There are a few problems that prevent grails deploying to the JBoss application server. I will describe specifically how to deploy a grails 1.3.5 web application to the JBoss 5.1.0.GA Applicaton Server community edition.

A bug has been filed on the grails Jira server describing the problem. Please create a Jira account and vote for this issue so that it may get more attention. The issue is Grails-6953.

The first issue is that newer versions of hibernate require hibernate validator even though grails doesn't need it. This is Jira issue Grails-5606 and says that it was fixed in grails 1.2.2 but wasn't.

In the text of Grails-5606 there was a work around described by Graeme Rocher that solves the issue. The work around is:

In BuildConfig.groovy:
  1. Uncomment the JBoss maven repository
  2. Add the hibernate-validator dependency
runtime('org.hibernate:hibernate-validator:3.1.0.GA') {
excludes 'slf4j-api', 'hibernate.core', 'hibernate-comnmons-annotations', 'hibernate-entitymanager'

The second issue is that grails includes logging libraries that JBoss already includes. JBoss complains about this. There is a good post covering that issue here. The logging libraries can be removed from the grails war file by adding the following to the end of the BuildConfig.groovy file:

// Remove logging artifacts from war
grails.war.resources = { stagingDir ->
def toRemove = [
].each {
delete(file: it)

The third issue has to do with how grails creates the filename of the war. Grails constructs the war filename based on properties defined in The war filename is When deploying the grails web application to an environment for testing, we may not want to access the application like:

To get around this issue, we can create a jboss-web.xml file in the web-app/WEB-INF folder. The contents of the jboss-web.xml file are: