There and back again: Can you compile that snapshot?
- 20 December 2016
- journal article
- research article
- Published by Wiley in Journal of Software: Evolution and Process
- Vol. 29 (4)
Abstract
A broken snapshot represents a snapshot from a project's change history that cannot be compiled. Broken snapshots can have significant implications for researchers, as they could hinder any analysis of the past project history that requires code to be compiled. Noticeably, while some broken snapshots may be observable in change history repositories (e.g., no longer available dependencies), some of them may not necessarily happen during the actual development. In this paper, we systematically study the compilability of broken snapshots in 219 395 snapshots belonging to 100 Java projects from the Apache Software Foundation, all relying on Maven as an automated build tool. We investigated broken snapshots from 2 different perspectives: (1) how frequently they happen and (2) likely causes behind them. The empirical results indicate that broken snapshots occur in most (96%) of the projects we studied and that they are mainly due to problems related to the resolution of dependencies. On average, only 38% of the change history of the analyzed systems iscurrentlysuccessfully compilable.Keywords
This publication has 42 references indexed in Scilit:
- Diversity in software engineering research2013
- An empirical analysis of the co-evolution of schema and code in database applications2013
- An empirical study on inconsistent changes to code clones at the release levelScience of Computer Programming, 2012
- Open source software peer review practices2008
- An empirical study of code clone genealogiesACM SIGSOFT Software Engineering Notes, 2005
- Tool Writing: A Forgotten Art?IEEE Software, 2005
- When do changes induce fixes?ACM SIGSOFT Software Engineering Notes, 2005
- How history justifies system architecture (or not)2004
- Satisfying heterogeneous user needs via innovation toolkits: the case of Apache security softwareResearch Policy, 2003
- Two case studies of open source software developmentACM Transactions on Software Engineering and Methodology, 2002