Developers often use dependency managers to make updating dependencies easier. These dependency managers allow permissive declaration strategies to be used which automatically keep dependencies up-to-date. To prevent these automatic updates from breaking projects, developers can use version locking to lock specific versions in place. To investigate how version locking is used we have done research into version locking in projects using Gradle. We found that version locking is not widely adapted, as only 0.34% of our sampled Gradle projects contained a lock file. Our analysis into the use of version ranges in projects using version locking showed that only 29.5% to 44.4% of analyzed projects using version locking, used version ranges. This is surprising as version locking is most effective when using version ranges. Our research into the effect of version locking showed that in 18.2% of the analyzed projects, version locking prevented the build from failing. Looking into the negative effects of version locking, we found that 9.8% of the dependencies are at risk of being a vulnerability, as for these dependencies there are newer versions available which might introduce security patches.

As Open-Source projects grow in size and incorporate more and more external dependencies, developers increasingly rely on dependency managers such as Maven to manage version conflicts and automate dependency resolution. However, developers are often unaware of vulnerabilities in their dependencies or do not prioritise security due to the effort required to update dependencies, resulting from a lack of compliance with Semantic Versioning policies. This paper aims to motivate greater adoption of version ranges by empirically analysing a large selection of open-source Maven projects to determine the impact of fixed versions compared to version ranges and identify opportunities for safe updates. It also proposes TeSTer as a conceptual command-line tool that analyse dependencies and provides insight into security practices, release frequency, and SemVer compliance to support informed decisions when incorporating dependencies in a project.

The Maven ecosystem relies heavily on dependencies to provide functionality, but the relationships between these dependencies are not well understood. This paper introduces the concept of dependency families, where a group of dependencies are owned by the same entity and designed to be used together. We develop a method to detect these families using a combination of structural and statistical techniques, and apply it to the Maven Central repository. Our analysis reveals insights into the structure and trends of dependency families, including their size distribution, usage patterns, and version homogeneity. Specifically, we find that most families are composed of a small core of frequently used dependencies alongside many supplemental ones; that releases without code changes are surprisingly prevalent; and that while many dependencies in a family share version numbering, this is not consistent enough for developers to always rely on. Our findings have implications for developers, maintainers, and users of dependencies in the Maven ecosystem.

Java projects often depend on third-party libraries to support development, but intensive reuse can lead to version conflicts, a common manifestation of dependency hell. This paper presents an empirical study of 124 GitHub pull requests from 85 Maven-based Java projects that addressed such version conflicts. We investigate the phenomenon from three perspectives: developer effort, the role of Semantic Versioning (SemVer) and conflict resolution strategies. Our analysis reveals that activity-based effort metrics are often confounded by unrelated changes and automation, suggesting the need for qualitative validation. Despite widespread use of SemVer syntax, 80% of observed runtime errors resulted from forward incompatibilities not covered by SemVer and even SemVer-compliant library versions occasionally broke backward-compatibility. The most common resolution strategy was library harmonization (67.7% of PRs), often achieved through version alignment techniques. These findings highlight the limitations of relying solely on versioning conventions and emphasize the importance of proactive tools and practices for managing dependencies. All datasets and analysis scripts are publicly available to support further research.