A reliable dependency resolution process should minimize dependency-related issues. We identify transparency, stability, and flexibility as the three core properties that define a reliable resolution process and discuss how different dependency declaration strategies affect them. To increase the reliability of Maven's dependency resolution we identify two patterns of misuse, or smells, that commonly occur in Maven projects: the presence of used undeclared dependencies and conflicting soft version constraints. We introduce and evaluate a proof-of-concept method, MaRCo, designed to address these smells. MaRCo increases transparency by injecting used undeclared dependencies and balances stability and flexibility by replacing soft version constraints with compatible version ranges. The version ranges are generated through a dependency-specific approach to compatibility using bytecode differencing and cross-version testing. The empirical evaluation of MaRCo shows that while the ranges generated by the dependency-specific approach may be stricter than necessary, they are unlikely to contain breaking changes. Overall, we see that MaRCo is able to make the resolution process slightly more reliable, affecting 13% of dependencies in 71% of projects, in a way that is more stable than a soft constraint-only approach, and more flexible than a hard constraint-only approach.

Research on open-source software evolution gained popularity in the last decade focusing on the theoretical determining factors. Additional works studied growth patterns modeling using time series techniques on small projects and metrics samples or non-openly available larger datasets. Limitations in reproducibility and scalability of these methodologies add to the lack of research on time series methodologies applied to open-source software evolution. Thus, time series approaches from different domains are needed to address the multivariate nature of larger and variable samples of open-source projects and metrics time series data. This thesis aims to provide a reproducible and scalable framework to support researchers in studying open-source software evolution using patterns modeling, time series merging, multivariate time series clustering and multivariate time series forecasting. An openly available dataset of 1328 projects is built using relevant metrics extracted from a systematic literature review. The metrics time series are segmented and clustered to obtain generalized growth patterns: Steep; Shallow; Plateau. The sequence of patterns and their correlation are used to create three project clusters, from which prediction models for all metrics are trained to perform multivariate time series forecasting. Experiment results give confidence over the reproducibility and the scalability of the framework and show how the pattern shifts can be linked to real events in projects' histories. The thesis provides an additional perspective on open-source software evolution and can serve as a starting point for further studies.

In the modern digital landscape, cybersecurity threats are a significant concern, particularly for publicly accessible computer systems. Vulnerabilities, or flaws in system design, can be exploited by malicious actors to compromise system security and integrity. This paper explores the challenges of handling vulnerabilities in software dependencies from the perspective of system operators, responsible for managing and monitoring infrastructure. The investigation is structured into two main steps. First, a detailed exploration of DevOps methodologies and current vulnerability handling techniques reveals key limitations and areas for improvement. Based on these insights, a new solution is proposed to enhance system operators’ capabilities in terms of awareness, impact assessment, and actionability. To validate the proposed solution, semi- structured interviews were conducted with ten experienced software engineers. The analysis of these interviews, using grounded theory methods, helped to refine the proposed system’s concepts and assess its potential impact on industry practices. In the second step, a fully functional prototype was developed, featuring the ability to monitor and mitigate vulnerability triggers in Java services through instrumentation. The evaluation of the prototype shows that the proposed solution effectively increases the granularity of vulnerability handling and is feasible for practical implementation from the resource utilization perspective.

This paper examines the release practices of Java Maven Repositories on GitHub. Most prior research in this vein has been done on Maven Central, the largest Maven package repository. However, GitHub hosts 15.5 million Java repositories, and is left untapped. Additionally of interest is the fact that GitHub provides a competitor to Maven Central, GitHub packages. To this end, the paper establishes an index of all Java repositories on GitHub. Furthermore, this dataset also includes Maven configuration (POM.xml) files. Additionally, an in-depth analysis is done of a sample of 500 000 of those 15.5 million repositories. This sample ended up containing 170 798 Java Maven repositories that had those POM.xml files. In this sample we discovered that of those 170 798, 6 507 (≈ 3.8%) had set up distribution configuration. Maven Central ended up being the most popular but GitHub packages and others ended up being quite popular as well. In the external repositories configured in those Java projects we notice a distinct lack of GitHub packages, other repositories were still present. We theorize that the lower popularity of GitHub packages is because it requires authentication, which is not trivial to set up. We discuss several approaches that can improve this situation.

This paper presents a comprehensive experimental study on the use and impact of external repositories in the Maven ecosystem. For this research the prevalence, naming patterns, and potential risks associated with external repositories were analyzed. We analyzed 199,188 packages and found that 3.29% of projects employ external repositories. Our findings indicate a decline in the usage of external repositories over time, with one (1.85%) and two (0.72%) external repositories occurring the most. The usage of external repositories has no significant (p < 0.05) effect on the error rate. However, 19.85% of the errors of packages that use an
external repository are caused by one of their external repositories. Moreover, we found that 69.58% of the repository urls were unreachable. 19.31% of the unique ids have two or more different repository urls associated with them. Based on our findings, developers are urged to thoroughly evaluate their usage of external repositories and to consider checking their settings.xml and POM.xml files to
ensure no url or id collisions are prevent or causing unintended behaviour.

This study conducts an investigation of the challenges faced by aging projects in Maven Central, focusing on the issue of missing dependencies. Using the Maven Explorer indexer, we systematically examine the correlation between the age of a project and the frequency of dependency resolution failures. Our analysis reveals a notable trend: older packages in Maven Central are more likely to encounter dependency resolution issues compared to newer ones. A widespread cause that was identified is the reliance on repositories without Transport Layer Security (TLS). Through this research, we highlight the prevalent issues within the Maven Central ecosystem and also offer insights into common causes of dependency resolution failures. We advocate for uploading new versions of libraries to multiple repositories to mitigate these issues. This study reviews the current state of Maven Central and extends some of the findings to other package management systems, contributing to a broader discourse on software longevity and dependency management.

The Maven ecosystem, with an emphasis on Maven Central, contains a plethora of toy-projects. This paper addresses this problem by formulating a core containing the pillars of the Maven ecosystem, such that it can be exploited for research concerning li- brary quality. The construction of said core is done by analyzing the availability, relevance and depen- dencies of packages in the Maven ecosystem. It involves answering questions regarding the distri- bution of library usages, the dependencies of popu- lar libraries and the effect of a usage threshold fil- tering mechanism. We found the popular libraries to be utilized to an incredible extend, while their less popular counterparts are seldom, if ever, used. Delving into the creation of a core reveals its non- trivial nature, requiring intricate knowledge of the Maven dependency mechanism and its accompany- ing tools to construct. This paper explores the com- plexities, nuances and considerations involved.

Open Source developers typically use Git repositories to transparently store the source code of projects and contribute to the code of others. There are millions of repositories actively hosted on platforms such as GitHub. This presents an opportunity for sharing knowledge between related projects – the so-called digital siblings. Finding repositories similar to one's own can allow for better developer collaboration and knowledge transfer. However, due to the large volume of projects, manually locating digital siblings of a project can be difficult. Hence, this paper proposes a novel approach, based on the dependency structures of GitHub repositories, that allows for calculating inter-repository similarity and subsequently querying for similar projects. We aim to answer the research question: How can the dependency structures of GitHub repositories be leveraged to find their digital siblings? This research includes an empirical evaluation of various similarity metrics and clustering techniques for GitHub repositories. Our results show that dependency structures are a reliable characteristic for measuring similarity between projects. We also identify the specific metrics and clustering techniques as particularly efficient. Lastly, we propose and evaluate a composable similarity metric to allow our findings to be combined with the research of the other Research Project group members.

This study explores the feasibility of categorizing GitHub projects based on their interactions and activities, aiming to assist both researchers and practitioners in navigating the vast landscape of open-source software. Through experiments and analysis, key attributes contributing to project categorization are identified, paving the way for effective grouping of projects in terms of interactions and activities. Findings indicate distinct clusters among GitHub projects, highlighting the influence of interactions and activities on project categorization. The study underscores the importance of refining grouping algorithms and improving project categorization methods for future research. Future work could involve developing user-friendly tools to facilitate project discovery and exploring correlations between interaction related metrics and project development dynamics. Overall, this study contributes to advancing our understanding of project categorization on GitHub, facilitating more efficient knowledge sharing and collaboration within professional fields.

This paper aims to study the importance of considering the documentation side of GitHub repositories when assessing the similarity between two or more applications. Readme and Wiki files, along with Comments from the source files, are the dimensions proposed to be analyzed through our methodology and experiments. We propose a pipeline that first extracts text fragments from these dimensions and then applies Natural Language Processing techniques to further prepare our data for evaluation. To gather a similarity score, we first vectorize our processed data with TF-IDF and then use cosine distance to obtain the score. Combinations of the three dimensions, ranging from using only one dimension to using all of them, are considered throughout our study. Moreover, additional information has been extracted from the plain text, such as referenced URLs and License usage, the similarity of which was calculated using Jaccard distance. Two experiments were performed. The first one aims to observe the behavioral tendencies of our methodology applied to a small dataset, while the second one aims to validate our results. By evaluating them, we found sufficient data that supported our presented conclusion: documentation represents a valuable asset in gathering a pool of similar applications.

GitHub is an online platform that hosts millions of projects. Many of these projects have the same topic or share the same goal. Finding similar projects which can be used as role models, inspiration or examples can help developers meet their requirements faster and more efficiently. Previous studies have been successful in finding similar GitHub projects, but they do not share how well their proposed metrics indicate similarity.

Our research and analysis seek to find the contribution of source code identifiers to overall project similarity. We define project similarity and define each type of identifier we evaluate. After these steps, we extract the defined types of identifiers from a list of projects. From this list of projects, we use twenty projects as queries for our analysis. We then analyze all identifiers using techniques such as TF-IDF and LSA. Our findings are that combining all types of identifiers results in the highest chance of having the same topic when looking at the most similar project. We also find that splitting each identifier on its casing and combining all split identifiers results in the highest chance that the most similar project found is similar. We therefore see that source code identifiers are reasonably contributing to overall project similarities.

GitHub is the home of hundreds of millions of Open Source Software(OSS) repositories where users collaborate on projects and find inspiration for new ideas. Some of these projects have certain build configurations set up to make building, testing, and deploying the software more time-efficient and less error-prone. However, setting up the correct configurations usually requires a lot of time and a high level of knowledge. This paper aims to analyze the current practices for setting up build configurations like the Maven files and GitHub actions while clustering some of these practices based on the scope of the project. Thus, we provide useful information in terms of discovering similar projects based on the build configurations and discuss the feasibility of build configuration analysis. In summary, we provide a comprehensive analysis of project similarity based on Maven build configurations and workflow files, shedding light on the importance of build configurations for identifying similar projects, and laying the groundwork for future exploration in the realm of build configuration analysis.

Call graphs are useful tools for representing method relationships within software projects and correlations between dependencies. Although static analysis is a prevalent method for call graph construction, it has its limitations such as struggling with handling dynamic features and lambda expressions. In this research, we introduced an approach that utilizes test suites from public Java Maven projects to construct dynamic call graphs and then merge them with static call graphs. Our objective is to explore the efficacy of the merged call graph in uncovering additional information. We employed OPAL and Soot to generate static call graphs and Java agents to trace edges during actual execution. Subsequently, a merging procedure, coupled with a filtering mechanism, was implemented to eliminate duplications. We conducted vulnerability detection analysis to assess the results and a version analysis to investigate the potential for extending our approach by merging multiple versions. Our results indicated that the merged call graph offers a modest increase in edges compared to solely static analysis. Additionally, we discovered that vulnerability identification followed a comparable pattern, supporting the consistency of our methodology. Additionally, we discover that combining several minor/patch versions of a project is a successful tactic for enhancing test coverage. Our research highlights the value of using test suites from open-source projects to build more in-depth call graphs.

The escalating complexity of software systems in the digital age heavily relies on reusable code collections(packages) for their development and operation. Despite the numerous advantages of pre-existing libraries, managing dependencies can be intricate and time-consuming. This thesis focuses on enhancing package management tools through a decentralized, crowd-sourced approach to distribute the preprocessing load more effectively across the software development ecosystem. We propose a novel platform comprising a back-end server and a Maven plugin, fostering an efficient and collaborative environment for developers to share computational results. This platform not only alleviates server load but also allows for the storage and reuse of frequently used artifacts, thereby avoiding redundant computations and reducing production costs for users. This crowd-sourcing model empowers developers to seamlessly request and contribute analysis results, saving time and resources while benefiting the broader community.

The Maven Central Repository hosts over 11 million packages. As Maven itself is a build tool for Java, the majority of these packages are Java archives.
This research aims to analyze these packages and look into various build aspects of these projects (the research questions): are Java modules used, what Java versions are used and how is the compiler configured? This is done by downloading a subset of these packages and looking at both the final artifact and the attached Project Object Model (Maven configuration). Specifically, one version is randomly selected from each distinct package hosted on Maven Central and then analyzed.
This research helps inform Java language developers and library maintainers. It captures parts of the build system evolution over a span of more than a decade. Precisely, version adoption, reproducibility and desirable build features are all important metrics for project maintainers in any software ecosystem. In the end, 473352 packages were analyzed. Firstly, it was found that Java modules are rare: only 6919 (1.69% of the artifacts with an archive) of the packages use Java modules. Secondly, the most common Java version used is Java SE 8 (182476 packages) representing almost half of all analyzed packages. All long-term support versions (Java SE 8, 11, 17 and 21) make up roughly half of the available packages. Thirdly, only 54.98% of artifacts configure the Maven compiler plugin with the most used parameters being the source and target Java versions. The most common additional compiler flags are verbosity settings, providing more feedback and code analysis from both the linter and compiler.

Maven Central serves as the de-facto repository for distributing free and open-source Java libraries and components. Evaluating its present state and overall robustness is pivotal for enabling the community to make well-informed decisions concerning its future progression. Such informed decisions would undoubtedly benefit the collective community of developers. This study aims to empirically evaluate developer practices surrounding version control and package reproducibility on Maven Central by investigating (i) the reliability of repository links, (ii) preferences regarding repository hosting services, (iii) the utilization of tags/releases, and (iv) the reproducibility of packages. Our study revealed that 20.85% of packages had unreliable repository links, attributable to inconsistencies in field usage and missing data, highlighting lax submission guidelines. GitHub emerged as the dominant host, with a market share exceeding 90% most years, though regional alternatives, like Gitee, are gaining traction. 74.35% of packages used tags/releases; however, naming convention discrepancies between Maven Central and source code repositories were identified, hindering version tracing and reproducibility. Strikingly, only a 3.06% of packages were configured to attempt reproducibility. An even smaller subset was found to be fully reproducible.

Maven, a widely adopted software ecosystem for Java libraries, plays a critical role in the development and deployment of software applications. However, there exists a limited understanding of the composition and characteristics of the Maven repository, leaving users and contributors unaware of the contents they interact with. This research aims to address this knowledge gap by conducting a comprehensive analysis of Maven packaging and informing developers, library maintainers, security analysts, and the open-source community about Maven library practices. The research investigates the secrets of the Maven repository, focusing on Maven packaging. Using data from the POM file, Maven index file, and Maven repository, we analyze the distribution of packaging types, checksums, qualifiers, and file types within Maven libraries. The experiment involves examining 479,915 packages from the Maven repository, utilizing the POM file, the Maven index, the Maven repository and manual requests to the Maven repository. The results reveal that JAR is the packaging type in more than 75% packages across all sources, and inconsistencies are found among different data sources, highlighting the need for improved data consistency and reliability within the Maven ecosystem. Furthermore, the adoption of the sha256 and sha512 checksum algorithms remains limited, with only 1.4% of packages utilizing these secure hash functions. In terms of qualifiers, sources and Javadoc exhibit the highest prevalence, with adoption rates of 82% and 76% respectively. Moreover, class files and XML are identified as the most frequently packaged file types, encompassing 71% and 61% of the packages, respectively among a very diverse classification. These findings provide insights into Maven library characteristics and inform optimization of library usage.

While continuous integration has already been proven to positively affect software development, little is known about how it should be implemented based on project context. This paper investigates how CI pipelines are configured by analysing data mined from software projects on GitHub. This re- search has shown the continued rise of the CI plat- form GitHub Actions, which enables developers to broaden CI pipelines’ functionality due to great in- tegration into GitHub. Moreover, key differences between how jobs within pipelines are structured in Travis CI and GitHub Actions are outlined. These results can be used in future research, which will be aimed at connecting project context to CI setup with the goal of informing developers on maturing their CI configuration.

Continuous integration (CI) is a software engineering practice that promotes frequent code integration into a shared repository, improving the productivity within development teams as well as the quality of the software being developed. While CI adoption has gained traction, studies have examined its effective implementation and associated challenges. The idea that multiple contextual factors influence the adoption of CI prompts an exploration of suitable descriptive metrics for describing the CI practices employed. This paper aims to explore the metrics that best depict the level of maturity of a project, addressing the question: "What metrics can be used to describe the maturity level of a project?". With a lack of a comprehensive maturity framework, we leverage GitHub's API in an attempt to analyze various metrics to be used to create a framework for filtering projects.
Our findings indicate that project maturity cannot be captured by a single metric, but rather a combination of metrics reflecting different aspects throughout the project's lifecycle. Activity levels, including commits and pull requests, popularity indicators like stargazers, forks, and contributors, as well as repository size and age, emerge as primary indicators of maturity. By combining these metrics, a unified framework for categorizing mature projects can be established and further developed.

The Continuous Integration (CI) practice, has been rapidly growing and developing ever since it's introduction. This practice has been constantly providing benefits to developers such as early bug detection and feedback to development teams. In this study, we aim to identify the descriptive metrics that best illustrate the performance of the CI build stage, regarded as heart of the development process.

We conduct a small case study on repositories utilizing GitHub Actions, a CI tool that is relatively unexplored. Within this context, we classify projects using two performance indicators: build breakages and build durations. We examine two distinct sets of metrics in our analysis. The first set being build level metrics, which are closely linked to the build stage. The second set including project level metrics.

Our findings suggest that patterns traditionally associated with low breakages and durations are applicable to repositories employing GitHub Actions. However, understanding the relationship between project level metrics demands a more comprehensive approach, necessitating a thorough analysis of the project context for a holistic understanding of build performance.