Trisummit Technologies

I encountered this error while setting up a continous build system using the Bamboo system from Atlassian Software. Setting up Bamboo was not difficult at all. However, this problem occurred when I attempted to add a Maven2 project. If you are not familiar with Maven2, it is a build system for java web applications. When doing java web applications, most people either use ANT or Maven2 as the build tool. Anyways, I set up a valid project with a working pom.xml file, proper artifacts, struts framework, and the application builds and runs perfectly on my local machine. I even added some Test Cases so as to make certain the build server properly invoked the test cases. I added the project to subversion and attempted to add the project to the Bamboo continuous build server. Unfortuneatly, when I sumbitted the project, I was immediately handed a stack trace.

java.lang.IllegalArgumentException: When not aligning with a user install you must specify a local repository location using the setLocalRepositoryDirectory( File ) method.
at org.apache.maven.embedder.MavenEmbedder.createMavenSettings(MavenEmbedder.java:699)
at org.apache.maven.embedder.MavenEmbedder.start(MavenEmbedder.java:628)
at com.atlassian.bamboo.ww2.actions.admin.ImportMavenPlanCheckoutPomAction.parsePom(ImportMavenPlanCheckoutPomAction.java:219)
at com.atlassian.bamboo.ww2.actions.admin.ImportMavenPlanCheckoutPomAction.doExecute(ImportMavenPlanCheckoutPomAction.java:118)
at com.atlassian.bamboo.ww2.BambooActionSupport.execute(BambooActionSupport.java:705)
……..

As I searched for the solution to the problem, it appeared that this problem had been reported quite commonly to the Maven team – However, getting the details on how to fix it were not offered. The solution was rather simple.

MAVEN2 needed to be installed on the Linux server running the Tomcat instance with the Bamboo application. The M2_HOME and M2 path variables also needed to be set on the server.

One last thing to check on the Bamboo application is to make certain you have established a builder that works. The default Maven2 builder in Bamboo may not have the same path as the one you have installed. So you may have to specify your own builder to match the path of your Maven installation.

Once I had taken these steps, the Bamboo application no longer threw that stack trace and I was able to complete the installation of the project to the continuous build system.

We needed a solution that would integrate search between various independent web applications. For example, in the case with PowerGUI.org, we had the Jive Forums / Jive Integrated site which housed the discussion forums and a library of downloadable powerpacks – mostly XML files. Additionally, we had a wiki using MediaWiki that was used for a collaborative approach at internationalizing the application. There were also a small handful of bloggers that were active participants on the site who all blogged extensively on the topic of Powershell. Our chosen solution was the Google Mini. For the most part, the solution was perfect. However, we ran into one problem. The Google Mini was only licensed for 100,000 pages. When looking at the number of threads in the PowerGUI forums and the size of the wiki and blogs, we expected the page usage on the Mini to be maybe 15,000. However, it maxed out the 100,000 page count on the initial crawl.

After much investigation, we determined that the reason for the unusually high page count had to do with the Jive Application. Jive allows for an independent URL of not only threads, but for each message of each thread as well. This resulted in a high amount of duplicate content in the Google Mini. The problem was made worse with the user profiles. We had multiple websites all sharing the same user base. So for each website, each users profile was crawled again and again and again. No wonder our page count was out of site.

From the Crawl Diagnostics, I was able to determine that we were experiencing duplicate content with the following three pages: message.jspa, accountView.jspa, and profile.jspa. Furthermore “tstart” was also a part of the URL with a lot of duplicate content.

The solution was in the “Crawl URLs” section of the Google Mini. In that section is a subsection called “Do Not Crawl URLs with the following Patterns:”

From there, we added the following:

http://domainname.com/profile.jspa$
http://domainname.com/accountView.jspa$
http://domainname.com/message.jspa$
contains:tstart

These four lines added to the “Do Not Crawl” list (of course modified with the proper domain name) wiped out virtually all of the duplicate content while keeping in all of the necessary content to be searched on. The results were a success. We had a successful implementation of the Google Mini which we later ported to numerous communities.