The Example Application reborn!
10 May 2008The last remaining step in rebuilding the Example.ear file under the Maven approach was to create a Maven .ear project that pulled together all of the various .war and .jar projects into a single, deployable artifact. I created a new Maven project in my Rational workspace with the packaging specified as “ear” and used the Maven ear plugin to generate the .ear file with the following pom.xml configuration:
<?xml version="1.0" encoding="UTF-8"?>
<project
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<groupId>org.restafarian</groupId>
<artifactId>example</artifactId>
<packaging>ear</packaging>
<name>example</name>
<version>1.0</version>
<description>
The Example Application pulls together all of the Restafarian.org services
into a single .ear file with examples demonstrating their use.
</description>
<developers>
<developer>
<id>restamon</id>
<name>The Restamon</name>
<email>restamon@restafarian.org</email>
<roles>
<role>Developer</role>
</roles>
<organization>Restafarian.org</organization>
</developer>
</developers>
<scm>
<connection>
scm:svn:http://svn2.assembla.com/svn/restafarian/example/
</connection>
<developerConnection>
scm:svn:http://svn2.assembla.com/svn/restafarian/example/
</developerConnection>
<url>http://trac2.assembla.com/restafarian/browser/example/</url>
</scm>
<build>
<plugins>
<plugin>
<artifactId>maven-ear-plugin</artifactId>
<version>2.3.1</version>
<configuration>
<modules>
<webModule>
<groupId>org.restafarian</groupId>
<artifactId>core-web</artifactId>
<contextRoot>/core</contextRoot>
</webModule>
<webModule>
<groupId>org.restafarian</groupId>
<artifactId>identity-web</artifactId>
<contextRoot>/id</contextRoot>
</webModule>
<webModule>
<groupId>org.restafarian</groupId>
<artifactId>approval-web</artifactId>
<contextRoot>/approval</contextRoot>
</webModule>
<webModule>
<groupId>org.restafarian</groupId>
<artifactId>authorization-web</artifactId>
<contextRoot>/auth</contextRoot>
</webModule>
<webModule>
<groupId>org.restafarian</groupId>
<artifactId>example-web</artifactId>
<contextRoot>/example</contextRoot>
</webModule>
</modules>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>org.restafarian</groupId>
<artifactId>approval-web</artifactId>
<version>1.0</version>
<type>war</type>
</dependency>
<dependency>
<groupId>org.restafarian</groupId>
<artifactId>authorization-web</artifactId>
<version>1.0</version>
<type>war</type>
</dependency>
<dependency>
<groupId>org.restafarian</groupId>
<artifactId>core-web</artifactId>
<version>1.0</version>
<type>war</type>
</dependency>
<dependency>
<groupId>org.restafarian</groupId>
<artifactId>example-web</artifactId>
<version>1.0</version>
<type>war</type>
</dependency>
<dependency>
<groupId>org.restafarian</groupId>
<artifactId>identity-web</artifactId>
<version>1.0</version>
<type>war</type>
</dependency>
</dependencies>
</project>
At this point, I have only done three things with this project: 1) right-click and Run As -> Maven install to generate the .ear file, 2) right-click and Run As -> Maven build… to generate the project web site, and 3) right-click and Team -> Share Project… to commit the project artifacts to the Subversion site on Assembla. I have NOT deployed the .ear file to WebSphere or attempted to run it in any way shape or form. I have no idea at this point if it even works, but since I was able to generate the .ear file, I considered that a major accomplishment and decided to stop and write it up!
Now that that’s over, I guess it’s time to find out if it actually works!
Upgrading WordPress
10 May 2008Every time that I log into this blog to do something, WordPress reminds me that my software is not the most recent version. Personally, I could really care less, but it’s relentless — it just won’t let it go. “You’re old and out of date” … “You’re old and out of date” … “You’re old and out of date” … it just never ends. My personal philosophy is more along the lines of “If it ain’t broke, don’t fix it!” but after constant nagging day after day after day, sometimes you just don’t have the will to resist any more. So, yesterday I finally broke down and started looking into what it would take to get the damn thing to just shut up about it.
To start with, I backed up the file system and the database. Not that I’m paranoid or anal or anything — you can just never be too careful about these things. Newer doesn’t always mean better, and if you’re not looking out for yourself, then who will be? Then I went over to the WordPress web site to download the latest version, where I stumbled across this:
Tip: The WordPress Automatic Upgrade plugin can greatly simplify the upgrade process, allowing you to upgrade your blog in about 2 minutes by clicking through a series of on-screen tasks. If you use the plugin, choose the manual rather than automatic mode.
That sounded like a good idea to me, so I grabbed the plugin and installed it. Now I grant you, I have nothing with which to compare my own experience, but I have upgraded a lot of products over the years, and I have to say that this particular upgrade using this plugin went remarkably smooth. It stepped you through the process, one item at a time. clearly explained what was about to happen, executed its tasks flawlessly, and the whole process was quick, easy, and painless. Just the way I like it!
I do have to say, though, that when it was all said and done, I wrote a quick post saying pretty much what you just read, clicked on the “Publish” button on my way out of the room, and never looked back to see the result. This morning, I went out to take a look at the post, since I didn’t have time to review it last night, and it’s nowhere to be found. It’s not published, it’s not in drafts, it’s not anywhere. Now I can’t say for 100% sure that I clicked on “Publish”, but I’m pretty damn sure that I did, and there’s no “Delete” button anywhere near the “Publish” button, so I’m a little concerned. But then, it’s probably just operator error.
Still, I’m curious to find out what is going to happen to this one once I push that button …
Update: Well, this one published just fine, which just goes to show you that The First Rule of Programming doesn’t just apply to programming!
Almost there … (still!)
8 May 2008As it turns out, I lied yesterday. I thought that I was through converting the “service” applications, but I forgot about the Identity Service. I have converted that one and the example application, so now the total list of projects looks like this:
- http://www.restafarian.org/projects/approval/
- http://www.restafarian.org/projects/approval-web/
- http://www.restafarian.org/projects/authorization/
- http://www.restafarian.org/projects/authorization-web/
- http://www.restafarian.org/projects/core/
- http://www.restafarian.org/projects/core-web/
- http://www.restafarian.org/projects/example-web/
- http://www.restafarian.org/projects/identity-web/
- http://www.restafarian.org/projects/skin/
Of course, none of these have any unit tests set up for them, and I haven’t even thought about doing something with the Checkstyle errors that are being generated by the project reporting, but at least they are all out there now. It’s a start.
The only thing left to do is to create the example .ear file that pulls all of these other projects together into a single, deployable demo where you can see examples of all of the various services at work. When these were all straight Rational projects, I knew how to connect all of the dots, but now that they are Maven projects living inside of Rational, I’m not exactly sure how to accomplish that same thing. I’d really like to be able to generate the .ear file and deploy it to the local WebSphere test environments that I have running inside of Rational, but I haven’t yet found a Maven2 plugin for WAS 6.x.
It;s probably just a matter of time before that shows up somewhere, but in the meantime, I’m going to have to figure out how to make it all work in some fashion. I guess I need start looking at the basic .ear plugin to start with.
Almost there …
7 May 2008Little by little I am slowly getting everything moved over into the new workspace on my Rational environment, getting things set up as Maven projects, generating the project web sites, and committing all of the artifacts to the Subversion repository on Assembla. At this point, the list of project web sites now looks like this:
- http://www.restafarian.org/projects/skin/
- http://www.restafarian.org/projects/core/
- http://www.restafarian.org/projects/approval/
- http://www.restafarian.org/projects/authorization/
- http://www.restafarian.org/projects/core-web/
- http://www.restafarian.org/projects/approval-web/
- http://www.restafarian.org/projects/authorization-web/
This completes the list of “service” components; all that remains is to move over the example web application along with the .ear project that pulls everything together and demonstrates the various services. I’m still not exactly sure how the .ear should be set up as a Maven project in order to get it to build the .ear file with all of the .war files and dependent .jar files inside, but we’re not quite there just yet, so there’s no need to worry about that today!
Maybe tomorrow …
Chipping away at the to-do list …
6 May 2008Now that I have pretty much figured out what I want to do with Maven and Subversion for my little project, all that is left is to sit down and actually do all of the work to get everything converted over. It’s not difficult work, but some things just take time. For each component of the completed .ear file, I have been doing the following steps:
- Create a new Maven project in the new Rational (Eclipse) workspace,
- Import the Java artifacts and other resources from the old project/workspace,
- Add all necessary dependencies,
- Update the pom.xml file with my site generation information,
- Create the site.xml file in the /src/site folder,
- Do a right-click on the project and select Run As -> Maven install,
- Generate the project web site and copy the artifacts to the web server,
- Do a right-click on the project and select Run As -> Maven clean,
- Do a right-click on the project and select Team -> Share project to store the project artifacts on the Subversion instance on Assembla, and
- Rinse, repeat.
One of the things that I did NOT do was to create JUnit tests for all of the projects at this stage. I want to do that, but right now, I just want to get everything set up under the new structure, and then I’ll go back and do that as time permits. I know … that’s not TDD, but then, this wasn’t a TDD project when it started, so there’s going to have to be a little after-the-fact catching up to do.
So far, I have completed four of the .ear project components. Their Maven-generated web sites are here:
- http://www.restafarian.org/projects/skin/
- http://www.restafarian.org/projects/core/
- http://www.restafarian.org/projects/approval/
- http://www.restafarian.org/projects/authorization/
The project artifacts that have been stored on Subversion can be seen here:
- http://trac2.assembla.com/restafarian/browser/skin/trunk/
- http://trac2.assembla.com/restafarian/browser/core/trunk/
- http://trac2.assembla.com/restafarian/browser/approval/trunk/
- http://trac2.assembla.com/restafarian/browser/authorization/trunk/
That’s just a start, though — there’s still plenty more to do, so I best get back to it!
More fun with Subversion
5 May 2008Yesterday, I committed my Maven skin project to Subversion on Assembla. Today, I did the same with my core components project. You can now find the complete set of project artifacts here. Once I pushed everything to Subversion, I updated the pom.xml file of the project to identify the Subversion information and regenerated the project’s web site. You can now find the updated web site here. Complete information the Subversion element can now be found here.
I still don’t quite understand why the Cobertura Test Coverage Report doesn’t pick up the fact that I built some tests for the BetwixtTool, but I’ll need to figure that out later. Right now, I need to get busy and get all of the other projects into Maven and into Subversion so that I can get back to the business of integrating OpenID into the whole process. First things first, though — now that I’ve started down this Maven path, I need bring in all of the rest of the parts and finish it up.
Some things just take a little time …
Fun with Subversion
4 May 2008One the sections of the standard generated Maven web site is Source Repository. Since I haven’t been keeping the source code for my little projects anywhere but on my local machine, Maven generated the following text for that section of the sites that it generated for my projects:
Source Repository
No source configuration management system is defined. Please check back at a later date.
I wanted to fix that, and my first thought was to go set up a project on SourceForge, which I have done in the past, but there’s an application process involved, and you have to wait for your project to be approved, and well … I just didn’t feel like going through all of that, so I started looking for something else. Eventually, I found Assembla, the self-proclaimed “… collaborative workspace for agile teams.” They offered Subversion, which is the next generation of CVS, so I set up a Space for all of my stuff at http://www.assembla.com/spaces/restafarian, which also set up a Subversion repository at http://trac2.assembla.com/restafarian/browser.
Once everything was set up, I went into my Rational Application Developer and opened up the SVN Repository Exploring perspective and connected to my new Subversion instance. Once I successfully connected, I closed that perspective and went back to my Package Explorer, right clicked on my Maven skin project and selected Team -> Share Project… to bring up the panels where I connected my project to the Subversion repository. Once connected, I committed all of the current artifacts to the repository, which you now view here.
Now, to update the Maven generated report, I needed to add the following information to the pom.xml file:
<scm>
<connection>
scm:svn:http://svn2.assembla.com/svn/restafarian/skin/
</connection>
<developerConnection>
scm:svn:http://svn2.assembla.com/svn/restafarian/skin/
</developerConnection>
<url>http://trac2.assembla.com/restafarian/browser/skin/</url>
</scm>
Of course, once I did that, the pom was out of sync with the repository, so I needed to commit that one all over again, but before I did that, I thought I better regenerate the Maven web site and make sure everything came out all right. You can see the newly generated Source Repository page here. Once that was done, I did another right click, Run As -> Maven build… to run the Maven clean goal to remove the generated report before committing everything back to Subversion one last time.
Assembla offers quite a number of other resources along the with project space, which I am going to have to explore in more detail one day, but for now, the Subversion repository is enough to start with. I still haven’t explored all that Maven can do, so I don’t want to even think about exploring all that Assembla can do — at some point, I have to get back to the actual work that I was doing some time ago, which was integrating OpenID authentication into the sample application. One day, I really need to get back to that!
Something new to play with …
4 May 2008
I just stumbled across ID Selector from JanRain, Inc., the folks responsible for myOpenID. ID Selector is a widget that you add to the existing OpenID login form on your website. You can get more details from the web site’s FAQ. According to the site:
It’s all about getting users signed into your website as quickly and efficiently as possible. It achieves this by providing a simple, consistent, provider neutral interface, and by educating the user about OpenID during the sign in process. In short, it makes OpenID easier for the end user and benefits both the relying parties and OpenID providers.
I need to finish moving everything to Maven before I get distracted yet again with something new, but once that’s done, I think I’ll try to add this to the JOID implementation of the Example application.
But not today!
Yet even more fun with Maven “look and feel”
3 May 2008It took a little longer than I originally thought that it should, but I now have my new Maven site skin in use in my first Maven project site. You can see the results here. Obviously, there are still a number of issues to be worked out, but it’s a nice start.
To be honest, it was actually a simple process, and should not have taken much time at all. To activate the skin for the core components project, all I needed to do was to copy the site.xml file from the skin project into the core project and change a couple of values. A right click on the project to bring up the context menu and a Run As -> Maven build… followed by entering the target site:site and clicking Run should have been all that it took to complete the process. However, it took me more iterations than I care to admit, tinkering with various other settings in the pom.xml and site.xml files, before I realized that I had copied the site.xml file to /src/main/site and not /src/site where it belonged. Once I fixed that (and put everything else back the way that it was!), everything came out just the way that mother nature intended.
I still have a few questions, like why the skin’s site.vm template seems to be in use in most pages, such as this one, but does not seem to be in use in other pages such as this one (you can tell the difference in the header). I’m not sure what causes that any more than I am sure why my Cobertura report says that I have 0% test coverage, but I imagine that I will figure it all out at some point. It’s a decent start, but I still have a lot to learn …
Even more fun with Maven “look and feel”
3 May 2008My first attempt at building a Maven skin is now complete enough to publish. You can take a look at the results here. Basically, I was just trying to carry over the branding from the blog into the Maven project site(s). It’s not beautiful, but it does at least have somewhat of a similar look and feel to it. One thing that I have not quite figured out yet is why the menu is collapsed on some pages and not on others. I’m sure that’s a setting somewhere; I just haven’t taken the time to track it down. I really like that, though; since the menu doesn’t have much on it anyway, I would just as soon have it expanded on every page. One day, I’ll have to fix that.
As with all of my other projects, I built the Maven skin project in IBM’s Rational Application Developer, which is based on Eclipse. When I first started playing around with Maven, I installed the Maven Integration for Eclipse plugin into my Rational Application Developer using the embedded Eclipse update feature. The plugin allows you to create new Maven projects, run Maven targets, and perform various other Maven-related functions all within the IDE. To create the skin project, I just clicked on File -> New -> Project … from the menu and then selected Maven project to bring up the new Maven project wizard. After filling in a few fields on the form, the plugin went to work and created the basic project shell in my workspace.
I wanted to accomplish two goals with this project: 1) create a new skin, and 2) use the new skin to generate the project site for the skin project. Both tasks turned out to be relatively easy once the project was created:
Creating the skin
All of the artifacts that make up the skin are placed in the /src/main/resources directory of the project. There are three primary elements to this particular skin:
- the style sheet, named maven-theme.css, stored in the /css directory,
- a collection of images, most of which I borrowed from the default theme, stored in the /images directory, and
- the Velocity template for the pages, called site.vm, stored in the /META-INF/maven directory.
Both the name and location of things are important, as the site generation process will look for certain elements by name in specific locations. If you want to see the modified .css file, you can find it here. The other thing that you should know about the names and locations of things is that Maven will actually place the completed skin in your local repository (${user.home}/.m2/repository) based on the information in your project’s pom.xml file when you run the Maven install target/goal.
Using the skin
To use the skin, I created a site.xml file in the projects /src/site directory. This file contains a number of elements, but the one that brings the new skin into the picture is, of course, the section enclosed by the <skin> tag:
<project name="Restafarian Maven Skin">
<version position="left" />
<publishDate position="right" format="MM-dd-yy"/>
<bannerLeft>
<name>Restafarian.org</name>
<src>images/restafarian.gif</src>
<href>http://www.restafarian.org/</href>
</bannerLeft>
<bannerRight>
<name>Site Skin</name>
</bannerRight>
<poweredBy>
<logo name="Maven" href="http://maven.apache.org/"
img="http://maven.apache.org/images/logos/maven-feather.png"/>
</poweredBy>
<skin>
<groupId>org.restafarian</groupId>
<artifactId>restafarian-maven-skin</artifactId>
<version>1.0</version>
</skin>
<body>
<menu ref="reports"/>
</body>
</project>
To create the skin .jar file and place it in my local repository, I right clicked on the name of the project and selected Run As -> Maven install from the context menu. To generate the site using the new skin is just slightly more complicated: I right click on the project and select Run As -> Maven build…, which brings up a panel where you can enter site:site (or just site, actually) as the goal and then I click on the Run button.
Now that I have my new skin, I can go back to my original .jar project and use it there as well. I still have a few reporting issues to deal with on that one, but once those are resolved, I can start looking at brining the rest of the example application into the Maven fold.








