Clover Development Hub

If you're doing custom development with Clover, you've come to the right place.

Bamboo and Hudson users: Clover already has working plugins that integrate Clover into these products (see the 'Clover Plugins' section below). No additional programming is required for Bamboo or Hudson users to take advantage of Clover.

The Clover API is aimed at CI server vendors wishing to add support for Clover to their products, or users wishing to program new solutions for meshing Clover's Test Optimization with your test framework (see the 'Reference Documentation' section below).

Clover Plugins

These plugins allow customers using continuous integration servers to easily make use of Clover's advanced code coverage analysis, in a turnkey solution.

Reference Documentation

Plugin Hosting on JIRA Studio​

Atlassian can host your plugin development project. We'll provide a Subversion repository, Confluence space and a JIRA project. Find out more.​

The Atlassian Developer Blog

For up-to-date news and opinions from the Clover, FishEye and other Atlassian development teams.

Atlassian Blogs » Developer (Software development and collaboration tools)
JIRA Development Cookbook — A book by Jobin Kuruvilla Jobin Kuruvilla, an experienced JIRA consultant and plugin developer, set out on the ambitious task to write a detailed and thorough book about JIRA plugin development. The result? A well crafted 450+ page book that starts by introducing the reader to Atlassian’s plugin framework and ends with useful recipes usually gained only by weathered experience. It’s a great read for Atlassian plugin developers at all levels. Bits of Goodness The JIRA Development Cookbook is filled with bits of great information that will not only teach the reader how to build great plugins, but also educate them on how JIRA is built. Jobin walks us through the various components used in the JIRA technology stack and exposes the architecture that you normally wouldn’t be able to see. Everything is laid out logically by order of interest to most JIRA plugin developers. Some of the more interesting topics Jobin covers are: Programming Workflows – workflow conditions, validators, and post functions Gadgets – introduction to OpenSocial gadgets and how to write them Searching with JQL and managing filters programmatically Issue CRUD basics UI customization – I found this very useful since these are common tasks many developers are asked to do Jobin also gives us a run through of how to access JIRA remotely through the SOAP and REST APIs. Unfortunately, this book doesn’t cover JIRA 5.0 which has a much more fully featured REST API. Lastly, I really appreciated Jobin’s recipes, some of which cover: Writing services, scheduled tasks, and listeners Customizing email content Adding new module types Creating issues and comments from email Summary I really enjoyed Jobin’s JIRA Development Cookbook. It’s great for beginning and advanced JIRA plugin developers. The publisher’s copy editing is a bit rough, but the breadth and depth of the content is great. Highly recommended! JIRA Development Cookbook, by Jobin Kuruvilla, published by Packt Publishing in November 2011. ISBN 978-1-84968-180-3. You can get it from Amazon.com.
What is Version Control: Diffs and Patches Much of the blog content was written in conjunction with Steve Losh. Steve is a programmer, photographer, blues dancer and musician. Check out Steve’s projects to see some of the cool things he has worked on, or jump over to his Bitbucket account and get straight to the source. Making the Switch to Distributed Version Control Many individuals, teams, and organizations are thinking about making the switch to distributed version control systems a la Git and Mercurial (Hg). This is the first post in a series of blog entries over the next several weeks that focus on using and understanding DVCS. Let’s start off with the basics and explore what version control is in general. In this entry, we will discuss problems that any version control aims to solve, where version control came from and some of the basic concepts you’ll need to know in order to use it. A Simple Example It’s often helpful to have a concrete example when talking about editing code, so let’s use a simple personal web page: 123456789101112131415161718192021222324<!DOCTYPE html> <html>     <head>         <title>John Doe's Site</title>     </head>     <body>         <header>             <h1>John Doe</h1>             <p>A Java programmer from Chicago, IL.</p>         </header>         <section>             <h2>About John</h2>             <p>John is experienced in many areas of Java programming.</p>         </section>         <section>             <h2>Contact Information</h2>             <ul>                 <li>Email: john@example.com</li>                 <li>Phone Number: (555) 555-1024</li>             </ul>         </section>         <footer>Copyright John Smith, 2010</footer>     </body> </html> We’ll use this simple HTML page as an example throughout this entry. Code Changes Often The code we write as programmers changes often. Bugs need to be fixed, features need to be added, and content needs to be changed. Most code is stored as plain old text files, and we change the code by editing these files. Every time we save our changes, we overwrite the old version of the file with a new one. Unfortunately, no programmer is perfect, and sometimes, we make mistakes. If you make a change to a file, save it, compile it, and find out that something went wrong, it’s often helpful to be able to go back to the old version or to get a report of what we actually changed, in order to focus on what we may have done wrong. Suppose in our example, our fictional character John wants to update his “Contact Information” header to read “John’s Contact Information”. He might edit the file so that that section reads: 1234567<section> <h1>John's Contact Information</h1> <ul>     <li>Email: john@example.com</li>     <li>Phone Number: (555) 555-1024</li> </ul> </section> John saves the file, reloads the page, and notices something doesn’t look quite right. How can John figure out the problem? In this simple example, it’s fairly easy to simply read the entire file and find the problem, but it can obviously get much more difficult when you’re editing many parts of a large file that all interact with each other. One of the earliest methods that is still around for comparing versions of files is a pair of utilities called “diff” and “patch”. Modern version control systems still use the concepts (and even file [...]
(Guest blog) On the Redistribution of Testing – Part 2 This guest blog post is part of an Atlassian blog series raising awareness about testing innovation within the QA community. You can find the other posts in this series under the QA Innovation tag.  This is a guest blog post by Paul Gerrard, a Principal of Gerrard Consulting Limited and is the host of the UK Test Management Forum. It is Part 2 of a two-part blog series on the future of QA testing. In Part I of this article on the Redistribution of Testing, I suggested there were four forces that were pushing testers out of the door of software projects (and into the real world, perhaps). In this post, I want to highlight the industry changes that seem to be on the way, that impact on development and delivery and hence on testing and testers. After the negative push, here’s the pull. These changes offer new opportunities and improve testers’ prospects. Recent reports (IBM’s ‘The Essential CIO’ 2011 study and Forrester’s ‘Top 10 Technology Trends to Watch’) put Business Intelligence, adoption of cloud platforms and mobile computing as the top three areas for change and increased business value (whatever that means). Once more, the industry is in upheaval and is set for a period of dramatic change. I will focus on adoption of the cloud for platforms in general and for Software as a Service (SaaS) in particular and the stampede towards mobile computing. I’m going to talk about internet- (not just web-) based systems rather than high integrity or embedded systems, of course. The Industry Changes its Mind – Again The obvious reason for moving to the cloud for Infrastructure as a Service (IaaS) and regardless of the subtleties of capex v opex costs, the cost advantage of moving to cloud-based platforms is clear. “Some of this advantage is due to purchasing power through volume, some through more efficient management practices, and, dare one say it, because these businesses are managed as profitable enterprises with a strong attention to cost.” So, it looks like it’s going to happen. Moving towards IaaS will save some money. The IT Director can glory in the permanent cost savings for a year – and then what? Business will want to take advantage of the flexibility that the move to the cloud offers. The drift from desktop to laptop to mobile devices gathers pace. Mobile devices coupled with cloud-based services have been called the ‘App Internet’. It seems that many websites will cease to be and might be replaced by dedicated low-cost or free Apps that provide simple user interfaces. New businesses with new business models focusing on mobile are springing up all the time. These businesses are agile by nature and Agile by method. The pull of the App internet and Agile approaches is irresistible. The Move to SaaS and Mobile (App) Internet I’m not the biggest fan of blue sky forecasters, and I’m never entirely sure how they build their forecasts with an accuracy of more than one significant digit, but according to Forrester’s report Sizing the Cloud, the [...]
(Guest blog) When 4/5 Dentists Agree, Why Do 4/5 Testers Disagree? This guest blog post is part of an Atlassian blog series raising awareness about testing innovation within the QA community. You can find the other posts in this series under the QA Innovation tag. The post is written by Lanette Creamer, an Agile testing consultant involved in software testing since 1999. Testers are prone to argue about anything. Just last night, at the Selenium Meetup, a fellow tester, Gary Masnica said, “There is nothing worse than listening to two testers argue. Before long, it will even get down to semantics, and I’m reminded of the Bill Clinton trial as each tester ponders the meaning of the word ‘the’ or something equally as silly.” Considering the small size of the testing community in relation to the number of developers, what gives? Are these testers just a cranky and cantankerous lot of malcontents? If so, surely not 4 out of 5 of them? Well, let’s first say that the title is a joke, because I’ve done no research, so those Dataphiles among you, please don’t go looking for the pie chart and research attached. Secondly, there IS something to it. Reasons for Disparity Critical Thinking First, to be effective as a software testers, you develop a different kind of critical thinking in order to find the exceptions to a given rule. It can be said that if you hear hoofbeats, think horses, not zebras. Testers know you’ve considered horses, but can you handle a herd of zebras? This is one reason why our arguments may sound strange to you, but when your code is on Safari, will you be less sorry? Varying Cultural Norms Secondly, testing is a HUGE profession than spans the entire globe. The education for testers is far from consistent, and there are these much debated “schools of thought” that some subscribe to. On top of that, we have testers who work in different stages of Agile transitions across the industry now. Call someone a “resource” in some company and you’d be better off to have cursed at them. Let’s just say that cultural norms vary. Even this combined with cultural differences across the globe don’t explain all that is going on. Making the Argument The third reason why testers often do not agree, even on things that seem simple to other people, is that testers need to convince other people in order to see changes happen. For many of us, the number of bugs we FIND isn’t important. It is only the number of bugs important enough to be fixed or that we prevented that adds value to the end user. We don’t intend to argue for bugs being fixed or prevented unless they ARE important, but when that bug is important, a good tester will be as convincing as a pitbull lawyer. There will be research, evidence, and convincing testimony from bystanders. By the time you’ve reached many years experience as a professional software tester, you are as adept at explaining risk and sharing information with others as a good insurance agent, [...]
JIRA 5 RubyGem One of the key features of the upcoming JIRA 5 release is the revamped REST API. This API gives you full access to creating, reading, updating, and deleting issues as well as other metadata related to issues. REST APIs provide for an easy and lightweight way to integrate with other apps using basic HTTP and JSON libraries. However, some developers might find it more useful to work on a client library that has a tighter interface to these REST APIs. Our friends at Trineo decided to build a RubyGem that does just that. Trineo’s jira-ruby gem was built just for JIRA 5’s REST API. It abstracts much of the boilerplate code that every developer has to deal with including OAuth. Here’s a sample of how to use the gem: client = JIRA::Client.new(CONSUMER_KEY, CONSUMER_SECRET) project = client.Project.find('SAMPLEPROJECT') project.issues.each do |issue| puts "#{issue.id} - #{issue.summary}" end issue.comments.each {|comment| ... } comment = issue.comments.build({'body':'My new comment'}) comment.save comment.delete It’s a great gem for working with JIRA 5. The best part is it’s open source, so feel free to fork it and send Trineo some new features.