This research explores the size variations of artifacts in Maven Central, a repository containing a large collection of Java artifacts. This analysis sheds light on the coding habits and dependency management ecosystems within Maven Central, emphasizing the importance of managing artifact sizes effectively. It also provides valuable insights to library maintainers and clients who want to download libraries. For example, we can determine the average amount of space required to download 100 libraries.
The analysis is done by selecting a single version for each artifact in Maven Central and extracting metadata from the corresponding files.
The results reveal that the average size of an artifact is 1447 KB, although this average is heavily influenced by a few exceptionally large artifacts. Approximately 86% of the artifacts have a size smaller than 400 KB, indicating that the majority of artifacts are relatively lightweight.
The large artifacts identified in the analysis are predominantly attributed to two categories. The first category contains extensive projects with a substantial number of files, while the second category includes machine learning or big data projects that include massive data files.

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.

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.

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.

In this paper, we investigate whether developers of artifacts on Maven Central adhere to semantic versioning. We also investigate whether there is a link between violations in semantic versioning and the popularity of the violating method. Developers can violate semantic versioning by removing or altering methods in their API, which we refer to as breaking changes. They can also violate semantic versioning by extending the API in a patch version, referred to as an illegal API extension. APIs that do not keep their promise of adhering to semantic versioning, will unexpectedly break their dependents during upgrading of dependencies.

We have found that these two types of violations do occur in practice. We find that 24% of analyzed artifacts contain breaking changes and 24% of artifacts contain illegal API extensions. Finally, we show that popularity of a method does not have an impact on breaking changes.

We conclude that semantic versioning can not always guarantee that upgrading dependencies will not lead to incompatibility. This indicates a need for developers to be more aware of the impact that violating semantic versioning has.

Even though previous studies have studied software artefacts on a package level, little research has been done on a method level. In this work, we perform a method-level analysis to determine how popularity disperses among methods within software libraries of Maven Central. We analyse 384 software artefacts with three different metrics: eigenvector centrality, degree centrality and dependent usage percentage. Using callgraphs of the interactions of a software artefact with its dependents, we can determine the relative popularity score of any method. We observe that popularity is inverse logarithmically distributed among the most frequently used methods within a library. Furthermore, 80% of calls to a library are to 26% of all methods, following the Pareto Principle. Likewise, the number of dependents per artefacts also follows a power-law distribution. We also find that no significant correlation exists between any of the analysed metrics, allowing opportunities for future research to determine a more accurate popularity metric. All of our results show that method popularity is logarithmically distributed within software artefacts of Maven Central.

Maven Central Repository hosts over 9 million repositories which ease software reuse. Since its appearance, Maven has been studied and character- ized using different popularity and quality metrics, in order to identify defining patterns and possible improvements. This study aims to analyze extent of use of packages released in the Maven Central Repository. Extent of use is a metric that quanti- fies how much of a package is used. The findings of this study show that on average 73.2% of avail- able methods and 77.1% modules in a package are used by dependents of the package. The study also shows that extent of use at method level is highly correlated with extent of use at module level (Pear- son correlation coefficient r = 0.829).

We look at the Maven eco-system and how popularity of packages and its methods change. We want to know if there are any trends that can help developers more efficiently use their time. To look at the popularity we do package analysis and method analysis. We find that there is no correlation between time and popularity on both the package and the method level. We do seem to find that developers are slow to adopt newer versions. We also found that library maintainers tend to re-release older versions, these versions often have low usage.

Dependency maintenance is a critically important part of software development as vulnerabilities and exploits are constantly being discovered. Unfortunately it is extremely tedious for developers to manually keep track of these vulnerability discoveries and update their dependencies consequently. Dependency maintenance tools such as Dependabot and WhiteSource help to make this job easier for developers but still many developers never update their dependencies even with notifications from these tools. As such this research paper aims to find if giving more information to the developer as to how the vulnerability affects their code entices developers more to update their dependencies. This research found that developers seem to not care much for extra information about vulnerabilities and in whole maybe a different approach is required to educate developers on the critical importance of dependency maintenance.

Software reuse in the form of dependencies has become widespread in software development. However, dependencies have the potential to suffer from vulnerabilities, thereby potentially putting depending projects at risk. Dependency analysis software can be used to manage vulnerable dependencies, such as Dependabot. Yet, such programs are generally inaccurate as a result of false positives, due to the limitations of package-level analysis. In the case of a false positive vulnerability recommendation, a software project imports a vulnerable dependency, but does not use any of its vulnerable functions. While most developers already do not pay enough attention to using vulnerable dependencies, false positives can only make this worse. Instead, function-level vulnerability analysis has the capability to eliminate package-level false positives. In this paper, research is performed to gain quantitative insight in the improvement of function-level over package-level analysis in terms of recommendation correctness. A package-level analysis simulation in combination with a function-level analysis was performed, built with the FASTEN framework. The latter uses RTA call graph generation and method tracing to remove package-level false positives. In total, 4071 open-source repositories were analyzed with 393 open-source vulnerabilities, of which 259 projects had positive recommendations. Comparison shows that 85\% of package-level recommendations are false positives, which are removed by performing function-level analysis instead. This indicates significant improvement by function-level analysis. Research on greater data sets would be needed for further insight in this improvement.

Nowadays software development greatly relies upon using third-party source code. A logical consequence is that vulnerabilities from such sources can be propagated to applications making use of those. Tools like Dependabot can alert developers about packages they use, which entail vulnerabilities. Such alerts oftentimes turn out to be false positives because the vulnerable functionality of the package is not used. Current research by the FASTEN Project revolves around analysing dependency networks using a finer granularity; moving from package-level to method-level analysis with the help of call graphs. Such analysis can theoretically be used to gain better insights into how vulnerable a dependency for an application is. This report aims to display the practical effectiveness of using call graphs to detect propagated vulnerabilities. To evaluate the effectiveness, results generated through method-level analysis were studied with regards to whether a vulnerability in the corresponding project is reproducible. Furthermore, possible improvements to call graphs to detect vulnerabilities more accurately are described in this study. An experiment, based on call graph analysis, was conducted to detect propagated vulnerabilities in a set of public software repositories. The used data about the repositories and vulnerabilities was provided by the FASTEN Project. Each vulnerability detection was manually verified and studied on its impact based on public information about the corresponding vulnerability. The results of this experiment show that none of the potential propagated vulnerabilities could be reproduced. This implies that a greater set of repositories needs to be analysed to draw meaningful conclusions for the effectiveness of call graphs to detect propagated vulnerabilities. The proposed improvements to call graphs display a fraction of the great potential of the precision that could be reached through such fine-grained analysis.

Modern software development involves the usage of external third-party software projects as direct dependencies. Nonetheless, developers of a dependant project have no control over critical aspects such as development and testing of the dependency. This can put the reliant repositories at risk through vulnerabilities, which can be exploited by malicious attackers. Automated dependency maintenance tools can mitigate the risks, but have an observed shortcoming: they have decreased vulnerability detection accuracies due to their package-level analysis approach.
In this study, a total of 6.717 active projects hosted on GitHub have been analysed using a method-level vulnerability analysis, discovering 24 projects affected by 4 distinct exposures. The developers have been notified through GitHub Pull Requests, which contained the methods in their projects that called vulnerable dependency methods. This was done with the aim of finding answers to: (i) whether the provided method call information makes developers prioritize the task of fixing vulnerabilities, (ii) whether the fine-grained information facilitates the exposures handling process.
Developers' reactions to the method-level data were collected through means of a survey. Collected data revealed that the fine-grained information in the PRs did have a positive effect on the developers' prioritization of fixing the vulnerable dependencies. Moreover, the provided data also facilitated the maintainers' fix process to some extent. However, due to the limited amount of recorded responses, the answer to the research question could not be concluded.