Exploring methods for dependency management in multi- repositories Design science research at Saab Training and simulation Main Subject area: Computer Engineering Author: Oskar Persson, Samuel Svensson Supervisor: Ragnar Nohre JÖNKÖPING 2021-07-15 This final thesis has been carried out at the School of Engineering at Jönköping University within Computer Engineering. The authors are responsible for the presented opinions, conclusions, and results. Examiner: Florian Westphal Supervisor: Ragnar Nohre Scope: 15 hp (first-cycle education) Date: 2021-07-15 i Abstract Dependency problems for developers are like sneezing for people with pollen allergies during the spring, an everyday problem. This is especially true when working in multi-repositories. The dependency problems that occur do so as a byproduct of enabling developers to work on different components of a project in smaller teams, where everything is version controlled. Nearly all developers use version control systems, such as Git, Mercurial, or Subversion. While version control systems have helped developers for nearly 40 years and are constantly getting updated, there are still functionalities that do not exist. One example of that is having a good way of managing dependencies and allowing developers to download projects without having to handle dependency problems manually. The solutions that version control systems offer to help manage dependencies (e.g., Git’s submodules or Mercurial’s subrepositories), do not enable developers a fail-safe download or build the project if it contains dependency problems. In this study, a case study was conducted at Saab Training and Simulation to explore methods for dependency management as well as discuss and highlight some of the problems that emerge when working with dependencies in multi-repositories. An argument can be made that the functionality of dependency management systems, both package managers and version control systems’ solutions are not up to date on how dependencies are used in the development, during this time. In this paper, a novel approach to dependency management is introduced with the possibility to describe the dependencies dynamically by providing the utility to describes usages of a repository (such as simulation of hardware or the main project). As well as discussing the necessary functionalities that are required to handle such a system. By re-opening the dialog about dependency management as well as describing problems that arise in such environments, the goal is to inspire further research within these areas. Keywords: dependency management, dependency problems, dependency conflicts, dependency hell, version control systems, git, mercurial, subversion. ii Table of content Abstract .......................................................................................... ii Table of content ............................................................................ iii 1 Introduction ............................................................................. 1 1.1 PROBLEM STATEMENT ...................................................................................... 3 1.2 CURRENT RESEARCH ........................................................................................ 3 1.3 PURPOSE AND RESEARCH QUESTIONS ............................................................... 4 1.4 SCOPE AND LIMITATIONS .................................................................................. 5 1.5 DISPOSITION ..................................................................................................... 5 2 Method and implementation .................................................. 7 2.1 DATA COLLECTION ......................................................................................... 10 2.2 ARTIFACT EVALUATION ................................................................................. 10 2.3 VALIDITY AND RELIABILITY ........................................................................... 11 2.4 CONSIDERATIONS ........................................................................................... 11 3 Theoretical framework ......................................................... 12 3.1 GIT ................................................................................................................. 13 3.1.1 Submodules ............................................................................................ 13 3.1.2 Subtrees .................................................................................................. 14 3.2 MERCURIAL ................................................................................................... 16 3.2.1 Subrepositories ....................................................................................... 16 3.3 SUBVERSION................................................................................................... 16 3.3.1 Externals ................................................................................................ 16 3.4 GOOGLE REPO ................................................................................................ 17 3.5 PACKAGE MANAGERS ..................................................................................... 17 4 Challenges with dependency management ......................... 19 iii 4.1 DIAMOND DEPENDENCY PROBLEMS .............................................................. 19 4.2 CIRCULAR DEPENDENCIES .............................................................................. 20 4.3 ALTERNATIVE DEPENDENCIES ........................................................................ 22 4.4 WORKFLOW ................................................................................................... 23 4.5 MERGING STRATEGIES .................................................................................... 25 5 Results ..................................................................................... 27 5.1 EVALUATION CRITERIA .................................................................................. 27 5.2 ARTIFACT ITERATIONS ................................................................................... 27 5.2.1 Iteration 1 ............................................................................................... 28 5.2.2 Iteration 2 ............................................................................................... 28 5.2.3 Iteration 3 ............................................................................................... 28 5.2.4 Iteration 4 ............................................................................................... 29 5.2.5 Iteration 5 ............................................................................................... 29 5.3 MANIFEST ...................................................................................................... 29 5.4 OVERLAY ....................................................................................................... 31 5.4.1 Gathering dependencies ......................................................................... 31 5.4.2 Dependency mitigation .......................................................................... 32 5.4.3 Cloning .................................................................................................. 32 5.5 GUIDELINES ................................................................................................... 33 5.6 RESEARCH QUESTIONS ................................................................................... 33 6 Discussion ............................................................................... 35 6.1 RESULT DISCUSSION ....................................................................................... 35 6.2 METHOD DISCUSSION ..................................................................................... 36 6.3 LIMITATIONS .................................................................................................. 36 6.4 RELATED WORK ............................................................................................. 37 7 Conclusions and further research ........................................ 39 iv 7.1 CONCLUSIONS ................................................................................................ 39 7.1.1 Practical implications ............................................................................. 39 7.1.2 Scientific implication ............................................................................. 39 7.2 FURTHER RESEARCH ....................................................................................... 39 8 Acknowledgments ................................................................. 40 9 References .............................................................................. 41 v 1 Introduction Developing software is a continuously ongoing process. According to Lehman, the law of continuing change “A program that is used and that as an implementation of its specification reflects some other reality undergoes continual change or becomes progressively less useful” applies to all software systems (Lehman; Lehman, 1980, p. 1068). Today, many larger systems are not developed monolithically but are instead divided into several components both internal and external (Florisson & Mycroft, 2015). This makes it more complicated as components have dependencies to other components in the system and that they are usually developed by different teams of developers. Even though most systems have moved from a monolithic development, the rules that were stated