Modern software systems are increasingly built as component-based architectures, e.g., as microservices. However, such architectural styles result in many challenges for development teams regarding issue management: Since the individual components are developed independently of each other, the teams manage the issues of the respective components often in separate issue management systems, making the tracking of cross-component issues much more dificult, i.e. issues that afect multiple components concurrently. To solve this problem, in previous work, we developed Gropius, which is a tool that acts as a wrapper for existing issue management systems enabling the management of issues across the diferent components managed in diferent issue management systems. While Gropius is particularly suitable for stakeholders who want to have an overall view of the architecture and the issues therein, a developer's daily work is primarily done in an IDE. Thus, frequent context switches between the issue management systems and the IDE reduce developer productivity, so IDE plugins for issue management have been developed in the past. However, these do not support cross-component issue management features as provided by Gropius. Therefore, in this work, we present Gropius-VSC, a Visual Studio Code extension that allows developers to manage cross-component issues directly in Visual Studio Code.
Component-based architectural styles, such as microservices, are becoming increasingly
common. Due to the independence in development and use of the individual components, these
architectures bring many advantages. At the same time, however, new challenges arise, such as
cross-component issue management: Due to the free choice of tools, the individual development
teams typically manage the issues of the components in independent issue management systems,
e.g. GitHub or Jira. As a result, tracking issues across component boundaries becomes much
more dificult [
Before we describe the concept of Gropius-VSC, we explain our research design. First, we
developed the concept by asking various stakeholders for the required features of such an
IDE extension. Based on these requirements and the Cross-Component Issue Metamodel [
The presented IDE extension Gropius-VSC is a client for the Gropius backend that supports the
Cross-Component Issue Metamodel [
Gropius-VSC consists of four components which are depicted in fig. 1: 1 a Component Detail View, 2 an Issue List, 3 a Issue Detail View, which is a detailed view of a single issue, and 4 Issue Bookmarks, which display the areas afected by an issue in a file. The sidebar next to the line numbers, which is also used for breakpoints, shows these issue bookmarks. After the IDE extension is configured for a Gropius project’s component, the Component Detail View 1 provides the current component’s name and description and issue filter functionality 5 . Additionally, the Issue List 2 shows all issues of the current component. This list can be filtered in the Component Detail View 5 by the status of the issue (open or closed), type of issue, e.g. bug report, and issues assigned to the developer using the extension. Issues assigned to the developer show a star in the issue’s icon. Furthermore, the Component Detail View provides a search bar to filter according to the issues’ titles and body matching to the filter text. The individual Issue Detail View 3 shows the title, body, issue type, labels and assigned users of the issue. Additionally, the semantical links to other issues 6 and artefact links 7 are displayed. Ingoing or outgoing issue links to another issue are hinted with an ingoing or outgoing arrow in the issue’s icon. The issue links can be traversed by clicking on the linked issue 6 , whereby the detailed view 3 always opens the linked issue. Furthermore, the linked issues and artefacts do not have to belong to the same component. If a linked issue concerns another component or the issue concerns multiple components, the detail view shows all afected components’ names next to this issue to clarify that this issue’s location is another component. A click on an artefact link opens the artefact, e.g. a source code file, in the text editor and jumps, if specified, to the area afected by the issue 9 . All artefacts are specified as URIs. An URI is opened in the web browser if it could not be transformed to a relative path to a file. In addition to displaying an issue in the detailed view, issues can be edited, e.g., changing the body text or adding new issue links and artefact links. Issue Bookmarks 4 in the sidebar show for a linked artefact file which areas are afected by an issue. However, the Issue Bookmarks contain only open issues to keep it more concise. Additionally, bookmarks cover a range of lines as shown in fig. 1. In the concept, clicking on an issue bookmark opens the issue which is linking to this artefact. However, since clickable custom sidebar elements are an open issue for VS Code, our extension contains a filter button 8 for issues linking to this artefact until this issue is resolved.
Component Detail Webview Typescript, Vue Js Issue Detail Webview Typescript, Vue Js, lit-element
Markdown Issue Body Renderer monaco editor, markdown-it
Messaging Messaging
Extension Core Typescript, VS Code Extension API
Issue List View
Component Quickselect Provider Editor Controller
Gropius Backend Connector Gropius Backend API
GraphQL
The architecture for Gropius-VSC consists of three main components: (1) the Extension Core, (2) the Issue Detail Webview, and (3) the Component Detail Webview. The components communicate with each other via messaging, which is handled by VS Code. Figure 2 shows the overview of the architecture. The extension is written in Vue JS and is open source available in GitHub2.
The Extension Core uses the Gropius’ GraphQL API in the Gropius Backend Connector component to communicate with the Gropius backend. The Component Quickselect Provider component is a QuickInput which sets the component’s id of the current workspace. This allows the user to search the name and description of all available components instead of setting the id in the settings manually. The Editor Controller decorates the TextEditor with Issue Bookmark icons. The Issue List View is a TreeView showing all issues of the current component. If the user clicks on an issue, the Issue Detail Webview opens this issue to show the details of the selected issue as stated in section 3 and enables editing it. The issue’s body is rendered with the Markdown Issue Body Renderer which consists of two parts: (1) a Monaco Editor (the same editor VS Code uses) for editing the body and (2) markdown-it with emoji plugin to render markdown. The Component Detail Webview displays information about the selected component and provides search and filter functionality for the Issue List View. VS Code Commands ofers some internal commands to the user, e.g. create a new issue, reload issue view, and check API connection.
VS Code’s flexible extension API allows web view extension panels which developers can develop using modern web development tools and frameworks. As a current limitation, custom sidebar elements like our Issue Bookmarks are not clickable.
In his PhD thesis [
The presented VS Code extension Gropius-VSC can improve issue management in componentbased architectures in a less error-prone and time-consuming way by allowing developers to manage cross-component issues directly in their IDE without context switches. In particular, traversing the links between issues of diferent components and opening the afected resources enables eficient issue management. Especially in systems with many components, this could significantly increase the focus on the issues that actually afect the developer’s components.