by Chris Boran

Several years ago I happened to be browsing in my favourite local bookstore and one book in particular caught my eye: Martin Fowler’s Refactoring: Improving the Design of Existing Code

This is the book that changed my whole career. Up until that point, I had lived in a constant state of fear of change. I viewed old code as a house of cards – if I wasn’t very careful, it was all going to come down around me. Whenever my boss asked me for advice about what to do in a given area of the code, my answers were almost always similar to:

The risk of doing anything but the smallest possible change is huge – so either we do something that is an ugly hack that we will regret later, or we need to take the whole thing apart and re-implement the whole subsystem from the ground up.

And predictably, my boss’s answer was always something like:

Okay, we will live with the hack for now, but in the next release we will make time to do it right.

Of course every release we were forced to make many similar decisions. When the next release would come, the newly conceived product features would get priority over fixing code that was already working passably. In practice we might get lucky and be able to spend lots of time rewriting a single small subsystem, but introduce ugly hacks that would put 4 other systems on the map for future re-implementation.

The end result is affectionately referred to as a Big Ball of Mud. Yup, it is every bit as pleasant as it sounds. Life is just so miserable when you come to work every day knowing you are going to have to pack another layer of mud on the ball. You gripe about it. Your teammates gripe about it. Your boss gripes about it. Somehow you never seem to make a whole lot of forward progress.

As I read the book, I was at first skeptical. I thought that bad old code needed to be thrown away and not revitalized! But I wanted to see if it would work, and so I set out to try it. I was very careful to follow the techniques exactly as they are laid out in the book. I made sure not to use the word refactor when I really meant rewrite. I was careful to refactor the code every time I saw something I wanted to change and not just note it for later. I made sure that my refactorings were small. I took my time with it.

Obviously working this way required that I also be doing very good unit testing, but I had already bought into Test Driven Development. I was already writing unit tests for code before fixing bugs in an attempt to prevent regressions. Running these tests after each refactoring was not a big challenge for me.

Bit by bit I discovered the truth. By applying the refactoring techniques, I could take pieces that I thought needed to completely rewriten and make them better while I was fixing bugs in that area. I could kill two birds with one stone.

Then I discovered Eclipse. The built-in refactoring browser captivated me. Suddenly there was a good, fool proof way to do many of the common refactorings, and automation to keep them introducing new errors. My commitment to refactoring was completed and the defect rates in the code that I was responsible for maintaining declined dramatically. I was a convert. Since that time refactoring has been a cornerstone technique in my arsenal. I no longer lived in fear and loathing of old code!

One refactoring that I have still found to be painful, despite Eclipse’s facilities, is renaming files/classes. In most software configuration management (SCM) tools, renaming files can have unfortunate unintended side effects because the identity of a file is its path. This leads to a great many developers to name a class once, and then never change its name – even if that name does not make sense and the design of the code and the classes primary purpose and responsibilities change.

Luckily for me, I am a long time Accurev user. In Accurev, files are not identified by their pathnames, but rather by a unique id. This makes it possible to quickly and easily rename files with no negative side effect. However this process was inconvenient – I would have to drop out of Eclipse, rename the file with Accurev’s tools, and then refresh my workspace. Not ideal, but it worked. That is why I was so pleased when the Accurev-Eclipse Plugin was released – it integrated the Eclipse Refactoring browser’s rename actions with Accurev’s capabilities to make the whole experience seemless. Accurev has helped me to maintain well thought out, easy to understand designs despite constant evolution to those designs.

Build management is a long-overlooked area of software development. As is often the case with underserved areas, the open source community has several good solutions. Maven is among the most interesting and functional solutions for Java developers. I had the chance to take the AccuRev-Maven m2eclipse integration out for a test drive recently. This is a recently announced integration (read the press release here if you are interested, and see my video demo here).

The integration follows the pattern of other software configuration management (SCM) integrations with m2eclipse. A backend provider interface was written to support AccuRev, and the provider was integrated into the m2eclipse environment via the SCMHandler mechanism. I used m2eclipse in conjunction with AccuBridge for Eclipse (the AccuRev-provided Team plugin) to materialize Maven projects into a new AccuRev workspace from within Eclipse, and then did some basic Maven build and AccuRev SCM operations.

To get started, I needed to install m2eclipse from Sonatype. I used the Eclipse Update Manager to do this, by creating a new remote site in Update Manager for Sonatype (http://eclipse.org/m2e/). I already had the AccuBridge for Eclipse plugin installed, also obtained via Update Manager (http://www.accurev.com/download/eclipseupdate). After restarting Eclipse, I was ready to test.

In my test environment, I had an AccuRev stream called maven_int that I had pre-loaded with (of all things) the source and test code for the Maven integration itself. My goal was to create a new AccuRev workspace based on this stream from within Eclipse that was Maven- and AccuRev-aware. To do this, I used the Eclipse Import functionality and selected the “Checkout Maven Projects from SCM” option. Since I was using AccuRev, I chose the AccuRev provider from the drop down list box. Like other integrations with Maven, AccuRev supports a URL format for specifying where to obtain code. The URL lets you specify the AccuRev user and login credentials, as well as the exact depot and stream from which to import the code. I also chose the make workspace checkout option, which tells the plugin to create an actual AccuRev workspace in a specified location.

After pressing the Finish button on the Import wizard, m2eclipse called out to AccuRev, created a new AccuRev workspace, and created new Eclipse projects (based on whatever Maven POM files were found in the maven_int stream) containing the source code. I then associated the Eclipse projects with AccuRev using the Team Share option so that I would have full access to AccuRev functionality.

Since the projects were all Maven-based, building was done by right clicking on the POM file and selecting one of the build options. To convince myself that the AccuRev functionality worked, I did some edits to a few files, saved the changes, and then used the AccuRev promote option to version that file in the AccuRev repository.

Overall, the integration worked as I expected. The installation of the plugins was fast, it was easy to materialize Maven-based projects from AccuRev, and all of the important Maven and AccuRev functionality was available in the respective plugins. If you are an AccuRev user and want to use Maven, then the combination of m2eclipse and AccuRev integrated inside of the Eclipse environment is a practical desktop tool for managing your local builds.

Related Recipes: AccuRev + Eclipse + Ruby.

In this developer-centric recipe I am going to setup a power-tool trifecta consisting of Eclipse, JIRA, and AccuRev. I’m not talking about installing each independently. No, no, no. This recipe is going to take things one step further and configure full bidirectional integrations for a wickedly powerful, fully integrated development environment where the majority of common day-to-day development tasks can be done right within Eclipse (right picture). Integrations are the crux of setting up a best-of-breed tool strategy and if you use these three tools you definitely want them talking together (left picture). Enough chop, let’s rock.

Install Applications

Let’s start by covering the basics and installing the latest versions of all three tools.

1. Install AccuRev 4.6.x. download. Follow the install wizard. See the quick setup guide to import code and setup streams [Windows page 1 / Linux-page 13].
2. Install Eclipse 3.3.x. download. Follow the install wizard. See documentation if needed.
3. Install JIRA 3.12.x. download. Follow these instructions.

At this point, you have three independent tools installed. Developers can checkin/checkout code from AccuRev, use Eclipse to modify the source code, and track bug/feature development with JIRA. In all, not a bad setup. But toggling between all these tools just takes valuable time away from coding and there is no mashing of logically related meta-data to generate useful reports… such as:

• “Which files/lines fixed issue #1234?”
• “Was bug #5678 fixed in mainline, 2.x, and 1.x codelines?”
• “Release is this Friday. How many issues are unresolved in the QA area and who are we waiting on?”
• “Which fixes went into Release 4.5.101?”
• “If I start working on the 4.x codeline, which known fixes will I be compiling against?”

Integrate Eclipse + AccuRev

Let’s eliminate jumping between Eclipse and the AccuRev CLI or StreamBrowser GUI. Rather, why not just keep/promote/update/merge directly within Eclipse. You can install our native Eclipse plugin via the Eclipse software updater.

1. Help –> Software Updates –> Find/Install
2. Select ‘Seach for new features to install’
3. Create ‘New Remote Site’ named ‘AccuRev’ with URL http://www.accurev.com/download/eclipseupdate/32
4. Checkbox ‘AccuRev’ and select Finish

When you create a new Project, choose to “Checkout from AccuRev.” Now the Eclipse ‘Team’ menu has a sleu of AccuRev commands available for inline use and your file navigator has icons for version control status. Sweet. Note: there is an AccuRev quickstart PDF located in your Eclipse plugin directory (e.g. /opt/eclipse/plugins/com.accurev.eclipse_4.6.1.32/UsingAB4Eclipse.pdf).

Integrate Eclipse + JIRA

Have you heard of the Eclipse Mylyn project? Seriously, it’ll bring a tear to your eye. In short, Mylyn is a generic framework for ‘task management’ within Eclipse and has a number of connectors to tools like JIRA, Bugzilla, and Trac. Guess what? You can interact with JIRA directly within Eclipse. It’s sick! seriously. Once again, you can install directly from the Eclipse software updater. First install the Mylyn framework and then the JIRA connector.

1. Install Mylyn 2.0. Follow this setup guide. Basically, just like the AccuRev plugin above, create a remote updater site with this URL: http://download.eclipse.org/tools/mylyn/update/e3.3
2. Install JIRA Connector. Follow the short setup guide provided by Atlassian.

As a developer, your world just got a whole lot better. Not only can you commit/update file changes directly within AccuRev, now you can open/close/update JIRA issues all without leaving Eclipse. Nuts!

Integrate AccuRev + JIRA

The final piece to the puzzle. Wait? What does hooking AccuRev to JIRA actually mean?!

Lets take a step back. Back in the day, using one of those other traditional branch-based SCM tools, you probably entered your bug #id into the commit comment. Commit 10 files. Enter bug #1234. Commit another 7 files. Enter same bug #1234. Very loose. And you probably had some validation and reporting scripts all stacked on top to keep things (hobbled) together. At the end of the day, this was far from a ‘tight’ integration and a struggle to maintain and enforce. Answering the simple question “which files -and- lines were fixed for bug #1234″ was not easy (probably impossible!).

AccuRev Change Packages. AccuRev has an out-of-the-box feature called Change Packages that natively tracks a set of files (as patches) regardless of the number of commits. Change packages are first class citizens in AccuRev. You can promote multiple times to the same change package and even remove files. The trick is to understand that a change package has a 1-to-1 relationship with… an issue! And those issues can come from JIRA. So as you work in your AccuRev workspace coding day-to-day you can promote your changes and assign them to a JIRA issue. Then make more changes and promote to the same issue. Think of it like this: creating a feature or fix may take 1 day or 100 days; 1 commit or 50 commits; Change packages don’t care. They just track the current set of files that you claim are ‘logically’ related as part of a fix or feature. That’s it! I’ll keep this short, but basically, you can now use the change package / issue as a new, first-class currency for promoting further up and/or patching those changes to other codelines! It’s very powerful. See pg 33 of our Concepts Guide for details. But I digress.

Back to the recipe. Hooking up AccuRev and JIRA means that AccuRev receives issues from JIRA and JIRA receives meta-data such as fixed files and versions for each issue. The setup requires our own connector technology called AccuBridge for JIRA. It’s pretty easy to setup and simply requires mapping JIRA fields to AccuRev fields and setting up the data synchronization. There is a well written ‘quick start’ guide to walk you through the entire setup process.

1. Install AccuBridge for JIRA. download (link half-way down). Follow the setup guide located in the download package: doc/ais4jira_quick.pdf. [Note: Additional licensing may be required]
2. Enable Change Packages. See pg 75 of the Admin Guide. Basically, you need to tell AccuRev ‘when’ to prompt users for issues, ‘which’ issues to query for, and which data columns to display in the lists. [Note: AccuRev Enterprise Edition is required]

At this point, developers are promoting file changes to JIRA issues and JIRA can report on ‘who’ fixed ‘which’ files for any given bug/feature/task. Now that’s what I call traceability!

All Together Now!

With everything hooked up, what do we have? Simple. As a developer you can do just about everything directly within Eclipse. Edit files. Commit and update changes from AccuRev. Create issues and update comments/status/fields in JIRA. And behind the scenes, the JIRA records are being annotated by AccuRev as files are promoted out of Eclipse. Eclipse is your one-stop-shop workbench for developing, tracking changes, and managing task workflow (see picture).

Next we’ll add a build tool to the mix that integrates with AccuRev, JIRA, and Eclipse… But that’s for another day. Sounds great though, doesn’t it!

/happy coding/ – dave

In the prior blog on this topic I talked about the types of data I wanted to collect for developer reporting, and the basics I had to do to get the information out of the AccuRev software configuration management tool and into the Eclipse BIRT tool in Eclipse.

I promised charts, but before I get there, I realized I had to do a little more work to massage the data for use with BIRT. When you do an issue query in AccuRev (see prior post) the details for AccuRev users are only exported as the id number. To get this to look nice I ran a second command (accurev show -fx users) to get the user information as xml data. Most AccuRev commands have xml output in the format of <AcResponse>…</AcResponse> so I then ran this result through another xsl parser. My xsl file is straightforward and looks like this:

<?xml version=’1.0′ encoding=’utf-8′ ?>
<xsl:stylesheet xmlns:xsl=”http://www.w3.org/1999/XSL/Transform” version=”1.0″>
<xsl:output method=”xml”/>

<xsl:template match=”/”>
<users>
<xsl:apply-templates select=”/AcResponse”/>
</users>
</xsl:template>

<xsl:template match=”AcResponse”>
<xsl:apply-templates/>
</xsl:template>

<xsl:template match=”Element”>
<user>
<number>
<xsl:value-of select=”@Number”/>
</number>
<name>
<xsl:value-of select=”@Name”/>
</name>
</user>
</xsl:template>
</xsl:stylesheet>

This generated user tags which I could then use as a lookup when converting the issue data. The output of running this gave me the following xml file (names removed):

<?xml version=”1.0″ encoding=”UTF-8″?><users>
<user><number>1</number><name>…</name></user>
<user><number>2</number><name>…</name></user>
</users>

I could now run the issue xml through another xsl translation, which would use the xml above as a lookup table for user details. The issue xsl I used looks like this:

<?xml version=’1.0′ encoding=’utf-8′ ?>
<xsl:stylesheet xmlns:xsl=”http://www.w3.org/1999/XSL/Transform” version=”1.0″>
<xsl:output method=”xml”/>

<!– Begin Lookup table of users –>
<!– Setup key –>
<xsl:key name=”user-lookup” match=”user” use=”number”/>
<!– Setup variable for users lookup file –>
<xsl:variable name=”users-top” select=”document(‘activeUsers.out’)/users”/>

<!– Setup match for lookup of users –>
<xsl:template match=”users”>
<xsl:param name=”curr-user”/>
<xsl:value-of select=”key(‘user-lookup’, $curr-user)/name”/>
</xsl:template>
<!– End setup match for lookup of users –>
<!– End Lookup table of users –>

<!– Setup match for submittedBy –>
<xsl:template match=”submittedBy”>
<xsl:apply-templates select=”$users-top”>
<xsl:with-param name=”curr-user” select=”.”/>
</xsl:apply-templates>
</xsl:template>
<!– End match for submittedBy –>

<!– Setup match for assignedTo –>
<xsl:template match=”assignedTo”>
<xsl:apply-templates select=”$users-top”>
<xsl:with-param name=”curr-user” select=”.”/>
</xsl:apply-templates>
</xsl:template>
<!– End match for assignedTo –>

<!– Setup match for closedBy –>
<xsl:template match=”closedBy”>
<xsl:apply-templates select=”$users-top”>
<xsl:with-param name=”curr-user” select=”.”/>
</xsl:apply-templates>
</xsl:template>
<!– End match for closedBy –>

<xsl:template match=”/”>
<xsl:apply-templates select=”/acResponse”/>
</xsl:template>

<xsl:template match=”issues”>
<issues>
<xsl:apply-templates/>
</issues>
</xsl:template>

<xsl:template match=”issue”>
<issue>
<issueNum>
<xsl:value-of select=”issueNum/.”/>
</issueNum>
<status>
<xsl:apply-templates select=”status”/>
</status>
<state>
<xsl:apply-templates select=”state”/>
</state>
<severity>
<xsl:apply-templates select=”severity”/>
</severity>
<priority>
<xsl:value-of select=”priority/.”/>
</priority>
<dateSubmitted>
<xsl:value-of select=”dateSubmitted/.”/>
</dateSubmitted>
<dateClosed>
<xsl:value-of select=”dateClosed/.”/>
</dateClosed>
<dateCompleted>
<xsl:value-of select=”dateCompleted/.”/>
</dateCompleted>
<dateAssigned>
<xsl:value-of select=”dateAssigned/.”/>
</dateAssigned>
<submittedBy>
<xsl:apply-templates select=”submittedBy”/>
</submittedBy>
<assignedTo>
<xsl:apply-templates select=”assignedTo”/>
</assignedTo>
<closedBy>
<xsl:apply-templates select=”closedBy”/>
</closedBy>
</issue>
<!– xsl:apply-templates/ –>
</xsl:template>

<xsl:template match=”status”>
<xsl:attribute name=”name”>
<xsl:value-of select=”.”/>
</xsl:attribute>
<xsl:attribute name=”value”>
<xsl:choose>
<xsl:when test=”.=’New’”>
<xsl:value-of select=”’1′”/>
</xsl:when>
<xsl:when test=”.=’Reviewed’”>
<xsl:value-of select=”’2′”/>
</xsl:when>
<xsl:when test=”.=’Scheduled’”>
<xsl:value-of select=”’3′”/>
</xsl:when>
<xsl:when test=”.=’Closed’”>
<xsl:value-of select=”’4′”/>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select=”’0′”/>
</xsl:otherwise>
</xsl:choose>
</xsl:attribute>
</xsl:template>

<xsl:template match=”state”>
<xsl:attribute name=”name”>
<xsl:value-of select=”.”/>
</xsl:attribute>
<xsl:attribute name=”value”>
<xsl:choose>
<xsl:when test=”.=’Verified’”>
<xsl:value-of select=”’3′”/>
</xsl:when>
<xsl:when test=”.=’Complete’”>
<xsl:value-of select=”’4′”/>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select=”’0′”/>
</xsl:otherwise>
</xsl:choose>
</xsl:attribute>
</xsl:template>

<xsl:template match=”severity”>
<xsl:attribute name=”name”>
<xsl:value-of select=”.”/>
</xsl:attribute>
<xsl:attribute name=”value”>
<xsl:choose>
<xsl:when test=”.=’A'”>
<xsl:value-of select=”’1′”/>
</xsl:when>
<xsl:when test=”.=’B'”>
<xsl:value-of select=”’2′”/>
</xsl:when>
<xsl:when test=”.=’C'”>
<xsl:value-of select=”’3′”/>
</xsl:when>
<xsl:when test=”.=’D'”>
<xsl:value-of select=”’4′”/>
</xsl:when>
<xsl:when test=”.=’E'”>
<xsl:value-of select=”’5′”/>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select=”’0′”/>
</xsl:otherwise>
</xsl:choose>
</xsl:attribute>
</xsl:template>
</xsl:stylesheet>

I had to scratch my head how to setup a lookup xml file, until I found this article on the IBM developerWorks site. It took some experimenting, but the xsl file above did the trick. I could have done a similar lookup for the status/state changes that are also in this xsl file, but it was quicker to enter these values directly. The side effect to keep in mind is because I don’t dynamically(today) get these values then if they change the xsl file needs to change.

After using this xsl file I get my new issue xml which looks like this (names removed and formatted for display):

<?xml version=”1.0″ encoding=”UTF-8″?>
<issues>
<issue>
<issueNum>1092</issueNum>
<status name=”Closed” value=”4″/>
<state name=”Verified” value=”3″/>
<severity name=”D” value=”4″/>
<priority>0</priority>
<dateSubmitted>943077600</dateSubmitted>
<dateClosed>1188926921</dateClosed>
<dateCompleted>1172186181</dateCompleted>
<dateAssigned>943077600</dateAssigned>
<submittedBy>…</submittedBy>
<assignedTo>…</assignedTo>
<closedBy>…</closedBy>
</issue>
<issue>
<issueNum>2614</issueNum>
<status name=”Scheduled” value=”3″/>
<state name=”Complete” value=”4″/>
<severity name=”C” value=”3″/>
<priority>0</priority>
<dateSubmitted>1007048693</dateSubmitted>
<dateClosed>1149106741</dateClosed>
<dateCompleted>1189024691</dateCompleted>
<dateAssigned>1120772200</dateAssigned>
<submittedBy>…</submittedBy>
<assignedTo/>
<closedBy>…</closedBy>
</issue>
</issues>

Phew. That being done, I now had a fairly automated method for extracting project issues, lookup tables for extraneous information, and xsl files to massage the data before processing in BIRT. Now I could bring the data into BIRT and begin setting up charts.

I spoke to some extent in the previous blog about the calculated fields I used in BIRT. I’ve since added a few more. I added a computed column which combines status and state, to make it easier to create certain chart groupings. Because these are two string fields it was as simple as putting in row["status"]+”/”+row["state"] as the expression.

I then also added the days to complete an issue, using this expression: (row["dateCompleted"]-row["dateSubmitted"])/86400

I now had enough information to create the 7 charts I wanted. I’ll highlight two that worked well for my purposes.

For completed issues by developer, I used the ‘assignedTo’ row as the Category (X) series, turned on grouping and set the interval to 0 so that each developer would get their own line. The Value (Y) Series was then the ‘issueNum’ row. From this I got the following chart:

Not bad, and it served my purpose. I could get a quick overview of how the issues were distributed. Some developers may cringe at seeing this type of information, as they fear they are not doing as much as their coworkers, but those reviewing the information have to keep in mind that there are lots of reasons for the issue distribution that is seen. Developers may be assigned more difficult work or not be on the project full time, and these basic numbers will not reflect the extent of these external factors. If you find you cannot easily answer these questions, then you need to find a way to track these external factors and include them in your issue management system.

For Severity Distribution, I wanted to take a look at what the general types of issues were that were resolved in the release. This was pretty easy. I created a pie chart, using issueNum as the series and severity as the category (grouping as text and getting the count). Using this I quickly got this chart:

Not a bad chart. Our use of severity A is in indication of crashes, so while some were fixed hopefully that is not the focus of the release. By the same token severity D and E cover a lot of cosmetic issues, so this release was a good distribution of the type of issues that should be addressed when preparing a release.

That’s about it for now. We’ve started adopting more agile practices, and in particular scrum methodologies, so now I want to revisit the BIRT configuration and start modifying it to generate burn down charts. Perhaps when I’ve made some progress here I’ll share some more.

As a developer I’ve found it necessary from time to time to generate reports, especially for internal consumption. Internal reports tend to be more adhoc than those presented to clients or non-technology managers, and therefore have less time devoted to their care and feeding (and cost). While I’ve used Crystal Reports and similar tools for external reporting, most development reporting has consisted of spreadsheets and any charts that they generate in the ten minutes I have before a review meeting.

Always wanting to explore various technologies, I took the opportunity to try my hand at using the BIRT (Business Intelligence and Reporting Tools) implementation in Eclipse. If you’re interested in finding out specifics about this plugin, you can find it on the Eclipse web site. While I find the tool to have a higher learning curve than I would have expected, it shows promise for the future.

There are a number of data points that we generate as part of our development, and capturing all of them in a report format proves to be a surprisingly complex task. It is a task that gets little time and investment, as development goals are not report oriented, they are product delivery oriented. I’ve attempted to capture some of the more mundane details, and set aside future report details that require a larger effort. I’ll be describing what I’ve done to create the reports, but not really discuss about why or how to interpret the data. A discussion of some other data and what you can do with it can also be found here.

Here at AccuRev our projects are issue oriented. We use AccuWork, which is our own tightly integrated issue management environment.

Given that, and the goals for the reporting that I defined, I had to find a way for AccuWork to communicate information that BIRT could interpret. In the past using Excel, I’d simply query issues in AccuWork and export the data into an HTML table that Excel could then read in and, with the help of pivot tables, generate the desired reports. The basic information reported included:

1. Number of issues per developer
2. Count of issues by priority per developer
3. Distribution of issue resolution (Whether issues are duplicates, regressions, cancelled, deferred, etc)
4. Distribution of issue severity (Whether issues are crashes, major implementations, cosmetic, etc)
5. Weekday issue completed per developer
6. Weekly Find rate vs. Fix rate
7. Weekly average number of days to complete issues

Using this information, it is easy to see projects taper off to closure, as well gather some ideas as to how the developer workload was being distributed. Some developers cringe at this information, but I believe as long as it is used positively and to evenly distribute work, then everyone gains from reviewing this information.

With these same charts in mind, I loaded up my version of Eclipse, installed BIRT and its associated plugins, and started to figure out how to get the data into the tool.

BIRT provides a number of different data sources, from file based to database, to XML. While I would like a little more flexibility in the XML source, like the ability to preprocess data before usage, it provided me with the means to bring in issues from AccuWork, with a little external help. The first thing I needed to do was get the information from AccuWork.

I used ‘accurev xml -l getActiveIssues.xml’. The getActiveIssues.xml file I used looks like this:

<acRequest>

<issuelist show_active = “true”>

<user>myUser</user>
<depot>myDepot</depot>
<stream1>myProjectStream</stream1>
<issues></issues>

</issuelist>

</acRequest>

This tells AccuWork to return the active issues in the depot for the given stream. This will return a full description of the issues, with all the fields populated. This is where I would have liked a preprocessor. Instead I massaged the data myself, removing fields like description. It wasn’t necessary, but given the number of issues fixed it can improve performance when you generate your report.

With this information I was able to generate charts to answer the first four questions. Now I was left scratching my head on the next set, so I went back to the spreadsheet to see how I had solved this problem. I realized after importing the data into Excel, I had a number of columns that were computed values. Here BIRT shows some flexiblity, with its own computed columns.

I added the <dateClosed> field that is part of the issue description in AccuWork to the column mappings in BIRT, and created a computed column and used the following as the formula:

( row["dateClosed"] – ( row["dateClosed"]%(60*60*24*7) ) ) / (60*60*24*7)

AccuRev communicates information in seconds, so using this calculation I can compute the number of weeks since Jan 1, 1970 when a particular issue was closed. I did the same for dateSubmitted and dateCompleted. Finally, I created a computed column to determine the weekday completed using this formula:

(new String(“SunMonTueWedThuFriSat”).substr( (new Date(row["dateCompleted"]*1000)).getDay() *3, 3 ) )

This one is a little messy, so let’s break it down. Using the bolded section I compute the day of the week as a numeric value (zero based, starting with zero as Sunday). I then used this value to determine the substring as an offset in a fixed length string. Not so bad, and avoided the dreaded mid-processor (something sitting between AccuWork and BIRT) that I was afraid I would have to write.

So, using a single query from AccuWork, and computed columns in BIRT, I now have the data I need to generate the 7 charts I described earlier. Next time I’ll talk about what I had to do to get the information to chart in BIRT, and show some of the output.

Related Recipes: AccuRev + JIRA + Eclipse (using Mylyn)

Love Ruby? Use Eclipse? Got AccuRev? Here’s a recipe guaranteed to get the mixture setup… stirred, not shaken.

Install Applications

1. Install AccuRev 4.5. download. Follow the executable wizard.
2. Install Eclipse 3.2. download. Follow the executable wizard.
3. Install Ruby 1.8. download. Follow these instructions.

Install AccuRev Plugin in Eclipse

1. Help –> Software Updates –> Find/Install
2. Select ‘Seach for new features to install’
3. Create ‘New Remote Site’ named AccuRev with URL http://www.accurev.com/download/eclipseupdate
4. Checkbox ‘AccuRev’ and select Finish

Install Ruby Plugin in Eclipse

1. Help –> Software Updates –> Find/Install
2. Select ‘Search for new features to install’
3. Create ‘New Remote Site’ named Ruby with URL http://updatesite.rubypeople.org/release
4. Checkbox ‘Ruby’ and select Finish

Lets Rock! Now that the software is installed, lets put it to work. Here are three use-cases depending on how you need to work on your project.

Use Case: New Eclipse project / New AccuRev workspace. Starting from scratch? Have ruby code already in a depot? Do you know which stream configuration you want to work from? Then this is for you…

• File –> New –> Project –> AccuRev –> Checkout from AccuRev
• Choose “Create new AccuRev workspace and Eclipse project”
• Follow the wizard to specify depot/stream/project/workspace names and directory location. Select ‘simple project’ when prompted for project type.
• Select project in navigator. Project –> Add Ruby Nature. This will declare the project as a ruby project.

Use Case: New Eclipse Project / Existing AccuRev workspace. Already have an AccuRev workspace with your ruby code? Just need to setup a new eclipse project? Then this is for you…

• File –> New –> Project –> AccuRev –> Checkout from AccuRev
• Choose “Create new Eclipse project in existing AccuRev workspace”
• Follow the wizard to select the workspace and name the project. Select ‘simple project’ when prompted for project type.
• Optionally, the project may need to be declared a ‘ruby project’. This may already have been done. Either way, select project in navigator. Project –> Add Ruby Nature.

Use Case: Existing Eclipse Project / Existing AccuRev workspace. Already have an eclipse ruby project? Is your project already on disk in an AccuRev workspace? Then this is for you…

• File –> Import –> General –> Existing Projects into Workspace
• Select AccuRev workspace directory containing the Eclipse .project file
• Checkbox the projects found then “Finish”
• Setup AccuRev for the project with: RClick Project –> Team –> Share –> AccuRev

Test either Use Case by creating a new Ruby Class. If you don’t get any errors, so far so good. Otherwise, if the ruby nature is not set, the new class wizard will warn you when you enter the class name. Now verify the new class shows up in Team –> AccuRev Searches –> External search view. This verifies that AccuRev is connected.

I hope this batch of recipes helps you get up and running flawlessly with AccuRev + Eclipse + Ruby in no time!

For those new to Ruby+Eclipse, our friends at IBM have a great tutorial. Also, the folks at O’Reilly have a great article about using Rails+Eclipse.

/happy coding/ – dave