Advertisement

Empirical Software Engineering

, Volume 17, Issue 4–5, pp 578–608 | Cite as

The evolution of Java build systems

  • Shane McIntoshEmail author
  • Bram Adams
  • Ahmed E. Hassan
Article

Abstract

Build systems are responsible for transforming static source code artifacts into executable software. While build systems play such a crucial role in software development and maintenance, they have been largely ignored by software evolution researchers. However, a firm understanding of build system aging processes is needed in order to allow project managers to allocate personnel and resources to build system maintenance tasks effectively, and reduce the build maintenance overhead on regular development activities. In this paper, we study the evolution of build systems based on two popular Java build languages (i.e., ANT and Maven) from two perspectives: (1) a static perspective, where we examine the complexity of build system specifications using software metrics adopted from the source code domain; and (2) a dynamic perspective, where the complexity and coverage of representative build runs are measured. Case studies of the build systems of six open source build projects with a combined history of 172 releases show that build system and source code size are highly correlated, with source code restructurings often requiring build system restructurings. Furthermore, we find that Java build systems evolve dynamically in terms of duration and recursive depth of the directory hierarchy.

Keywords

Build systems Software evolution ANT Maven Software complexity 

Notes

Acknowledgements

We would like to thank Linus Tolke, Tom Morris, and Bob Tarling of the ArgoUML development team for their assistance in validating our case study results, and the anonymous reviewers for their valuable feedback.

References

  1. Abreu R, Premraj R (2009) How developer communication frequency relates to bug introducing changes. In: Proc of the joint int’l and annual ERCIM workshops on principles of software evolution and software evolution workshops (IWPSE-Evol). ACM, New York, pp 153–158CrossRefGoogle Scholar
  2. Adams B, De Schutter K, Tromp H, Meuter W (2007) Design recovery and maintenance of build systems. In: Proc of the 23rd int’l conf on software maintenance (ICSM), pp 114–123Google Scholar
  3. Adams B, De Schutter K, Tromp H, De Meuter W (2008) The evolution of the linux build system. Electron Commun ECEASST 8Google Scholar
  4. Antoniol G, Guéhéneuc YG (2005) Feature identification: a novel approach and a case study. In: Proc of the 21st int’l conf on software maintenance (ICSM). IEEE Computer Society, Piscataway, pp 357–366CrossRefGoogle Scholar
  5. Apache Foundation (2010a) Apache ANT manual. http://ant.apache.org/manual/. Last viewed: 7 July 2010
  6. Apache Foundation (2010b) Apache Maven. http://maven.apache.org/. Last viewed: 18 March 2010
  7. Apache Foundation (2010c) Maven migration guide. http://maven.apache.org/guides/mini/guide-m1-m2.html. Last viewed: 2 September 2010
  8. Apache Foundation (2011) Maven build lifecycle. http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html. Last viewed: 13 April 2011
  9. Belady L, Lehman M (1976) A model of large program development. IBM Syst J 15(3):225–252zbMATHCrossRefGoogle Scholar
  10. Berger T, She S, Lotufo R, Wasowski A, Czarnecki K (2010) Variability modeling in the real: a perspective from the operating systems domain. In: Proc of the 25th int’l conf on automated software engineering (ASE). IEEE/ACM, New YorkGoogle Scholar
  11. de Jonge M (2005) Build-level components. IEEE Trans Softw Eng 31(7):588–600CrossRefGoogle Scholar
  12. Dmitriev M (2002) Language-specific make technology for the Java programming language. In: Proc of the 17th conf on object-oriented programming, systems, languages & applications (OOPSLA). ACM, New YorkGoogle Scholar
  13. Ebersole S (2007) Maven migration. http://lists.jboss.org/pipermail/hibernate-dev/2007-May/002075.html. Last viewed: 18 March 2010
  14. Feldman S (1979) Make-a program for maintaining computer programs. Softw Pract Exp 9(4):255–265zbMATHCrossRefGoogle Scholar
  15. Godfrey MW, Tu Q (2000) Evolution in open source software: a case study. In: Proc of the int’l conf on software maintenance (ICSM). IEEE Computer Society, Piscataway, pp 131–140Google Scholar
  16. Graves TL, Karr AF, Marron JS, Siy H (2000) Predicting fault incidence using software change history. IEEE Trans Softw Eng 26(7):653–661CrossRefGoogle Scholar
  17. Halstead MH (1977) Elements of software science (Operating and programming systems series). Elsevier, New YorkGoogle Scholar
  18. Knight S (2002) SCons design and implementation. In: Tenth int’l python confGoogle Scholar
  19. Kumfert G, Epperly T (2002) Software in the DOE: the hidden overhead of “The build”. Tech Rep UCRL-ID-147343, Lawrence Livermore National Laboratory, CA, USAGoogle Scholar
  20. Lehman M (1980) On understanding laws, evolution and conservation in the large program life cycle. J Syst Softw 1(3):213–221MathSciNetGoogle Scholar
  21. Lehman M, Ramil J, Wernick P, Perry D, Turski W (1997) Metrics and laws of software evolution—the nineties view. In: Proc of the 4th int’l software metrics symposium (METRICS)Google Scholar
  22. McCabe TJ (1976) A complexity measure. In: Proc of the 2nd int’l conf on software engineering (ICSE). IEEE Computer Society, Piscataway, p 407Google Scholar
  23. McIntosh S, Adams B, Hassan AE (2010) The evolution of ANT build systems. In: Proc of the 7th working conf on mining software repositories (MSR). IEEE Computer Society, Piscataway, pp 42–51CrossRefGoogle Scholar
  24. McIntosh S, Adams B, Hassan AE (2011a) ANT and Maven build logs. http://sailhome.cs.queensu.ca/~shane/
  25. McIntosh S, Adams B, Nguyen THD, Kamei Y, Hassan AE (2011b) An empirical study of build maintenance effort. In: Proc of the 33rd int’l conf on software engineering (ICSE). ACM, New YorkGoogle Scholar
  26. Miller P (1998) Recursive make considered harmful. In: Australian Unix user group newsletter, vol 19, pp 14–25Google Scholar
  27. Nagappan N, Ball T (2005) Use of relative code churn measures to predict system defect density. In: Proc of the 27th int’l conf on software engineering (ICSE). ACM, New York, pp 284–292. doi: 10.1145/1062455.1062514 CrossRefGoogle Scholar
  28. Neagu A (2010) What is wrong with Make. http://freshmeat.net/articles/what-is-wrong-with-make. Last viewed: 26 February 2010
  29. Neundorf A (2010) Why the KDE project switched to CMake—and how (continued). http://lwn.net/Articles/188693/. Last viewed: 6 March 2010
  30. Neville-Neal GV (2009) Kode vicious: system changes and side effects. Commun ACM 52(4):25–26. doi: 10.1145/1498765.1498777 CrossRefGoogle Scholar
  31. Robles G, Amor J, Gonzalez-Barahona J, Herraiz I (2005) Evolution and growth in large libre software projects. In: Proc of the int’l workshop on principles of software evolution (IWPSE), pp 165–174Google Scholar
  32. Robles G, Gonzalez-Barahona JM, Merelo JJ (2006) Beyond source code: the importance of other artifacts in software development (A case study). J Syst Softw 79(9):1233–1248. doi: 10.1016/j.jss.2006.02.048 CrossRefGoogle Scholar
  33. Tu Q, Godfrey M (2002) The build-time software architecture view. In: Proc of int’l conf on software maintenance (ICSM), IEEE Computer Society, Piscataway, pp 398–407Google Scholar
  34. Weirich J (2011) Rake—Ruby Make. http://rake.rubyforge.org/. Last viewed: 30 March 2011
  35. Wheeler DA (2011) Sloccount. http://www.dwheeler.com/sloccount/. Last viewed: 26 February 2011
  36. Zadok E (2002) Overhauling Amd for the ’00s: a case study of GNU autotools. In: Proc of the FREENIX track on the USENIX technical conf. USENIX Association, Berkeley, pp 287–297Google Scholar

Copyright information

© Springer Science+Business Media, LLC 2011

Authors and Affiliations

  1. 1.Software Analysis and Intelligence Lab (SAIL)Queen’s UniversityKingstonCanada

Personalised recommendations