This guide describes concepts, components and functionalities of OSLC Connect for Jira in order to create Collaboration Links between Atlassian Jira and any OSLC-enabled application [1], [2]. Unless required, the target application will be referred generically through this guide as the OSLC Remote Application.
A Collaboration Link is a link between two elements that belong to different applications. Typically, when a Collaboration Link is created from one Application A to one Application B, a back link is created (automatically) from Application B to Application A, so both elements may have a way to navigate to each other. In this scenario, where a link can exist either because it was created on its own, or because it was created as the back link of the other link, it is often useful to distinguish their nature with a role name:
Once installed and properly configured [3], OSLC Connect for Jira allows to create outgoing links in both ends [4]:
Given the complexity of some products, some applications have implemented what is called Configuration Management. When enabled, this feature allows to define different versions of a given artifact and group them in components. Let's say a company wants to create a plane, the complexity would suggest us to split the design, and process in general, in components: the cabin, the wings, etc. Now, the design requirements for such plane to fly on America may be different from those in Europe; by having different versions of the same components (and the artifacts on them) engineers could achieve all this work easier: one version for America, one for Europe.
A configuration is, in this context, a version of a component: as many different component versions a team need to work with, as many configurations they need to create. All this is good up to one wonder what configuration on RM application should work with what configuration of QM application? In a collaborative environment, different applications care about different parts of the making process and, in a Configuration-Management-enabled environment, it is important to establish a relationship between configurations (from different applications) that work together, here is where the concept of Global Configuration comes in. A Global Configuration (GC) is a configuration where the artifacts are also configurations... but configurations from different applications (RM, QM, etc) that work together. In other words, the global configuration is the mean to define which local configurations work together.
In Jira, it does not make sense to have different versions of an issue [5], this makes impossible to define a local configuration which could become part
of a GC, but OSLC Connect for Jira makes possible to create Collaboration Links to OSLC-enabled applications that do.
This is done by making use of the Jira Versions and the fields Affects Version/s and Fix Version/s, whose value can be mapped to a GC through a Collaboration Link type.
By having this mapping [7], and in other words, a Jira issue can be linked to remote versioned artifacts, depending on the GC mapped by the Jira Version set
on the Affects Version/s or Fix Version/s field; the actual field used to resolve the GC depends on the Collaboration Link type the user is creating [6].
Following topics will include a Global Configurations Compatibility section to describe the differences over the general behavior when GC's are not involved.
Given Jira users are not necessarily the same as the OSLC Remote Application users, this guide is divided in two sections aimed to them: