Search

Build systems are used to transform static source code into executable software. They play a crucial role in modern software development and maintenance. As such, much research effort has been invested in understanding the quality and evolution of build systems, including Apache ANT, Apache Maven, and Make‐based ones. However, the quality and evolution of build systems for mobile apps, such as on the Android platform, have not as yet been investigated in detail. Mobile app development, and the Android development context in particular, impose unique constrains, such as different device conditions and capabilities. It presents unique challenges, such as frequently upgraded Android frameworks, which those who implement and maintain build systems must tackle. In this paper, we present an exploratory empirical study of the build systems of 5222 Android projects to better understand their quality and evolution. We (a) study the build technology choices that Android developers make (Gradle being recommended and the most popular choice), (b) explore the sustainability of the official Gradle build system (parts of build files are updated more frequent that others and the update of the special Gradle plugin would induce unrecommended configurations), and (c) analyze the quality of Gradle scripts for Android apps—more than a half of the open‐source Android apps cannot be successfully built due to five common root causes. [ABSTRACT FROM AUTHOR]

Background and aims: Phytotoxicity following addition of hydrothermal-carbonised waste amendments (hydrochar) to soils is primarily attributed to toxic-organic compounds formed in hydrochars during hydrothermal carbonisation (HTC). However, factors influencing toxin formation in hydrochar and subsequent phytotoxicity have not been elucidated. Here, we investigated the effects of hydrochar feedstock and HTC temperature on phytotoxicity. Methods: Hydrochars from sawdust, rice straw, chicken manure, paunch-hair, pig manure, biosolids and digestate, produced at three HTC temperatures (170, 200 and 260 °C), were assessed for phytotoxicity using plant-bioassays, spectroscopy and wet-chemistry. Results: Hydrochar had no effect on seed germination, but reduced (30 to 50%) or had no significant effect on wheat growth under limited nutrient supply. Importantly, under luxury-nutrient supply, hydrochars (170 and 200 °C) that reduced growth in limited-nutrient conditions had no significant effect, and only hydrochars produced at 260 °C consistently reduced (20 to 30%) growth. Elemental-analysis and fourier transform infrared spectra indicated an increase in potential toxic functional groups in hydrochars produced at high temperature (260 °C). This suggested that phytotoxicity was due to toxic organic compounds, and occurred at high temperature. Conversely, at low temperature (170 to 200 °C), apparent phytotoxicity in nutrient-limited conditions was not due to hydrochar toxins, but nutrient deficiency exacerbated by hydrochar-induced nutrient immobilisation. Feedstock-type had no significant effect on phytotoxicity. Conclusion: Findings provide new understanding of hydrochar-induced phytotoxicity. Fundamentally, hydrochars (170 to 200 °C) are potential soil-amendments, but nutrition regimes to offset nutrient-drawdown need consideration. Research to mitigate toxicity in hydrochar-260 °C is warranted. [ABSTRACT FROM AUTHOR]

Food security depends on sustainable phosphorus (P) fertilisers, which at present are mostly supplied from a finite rock phosphate source. Phosphate (PO43−) and ammonium (NH4+) in dairy processing wastewater can be recovered as struvite (Mg + NH4+ + PO43− 6H20), a nutrient rich mineral for fertiliser application. The objectives of this study were to (1) quantify the effects of, pH, temperature and Mg: PO43− dosing rates on nutrient (PO43− and NH4+) removal and struvite precipitation from post anaerobic digested dairy processing wastewater, and (2) co-blend different dairy processing wastewaters to improve the reactant stoichiometry of NH4+ and PO43− for optimal struvite recovery and NH4+ removal. Phosphate removal (>90%) and struvite production (>60%) was achieved across a range of synthesis conditions, and was significantly impacted by pH as determined by response surface modelling. A combination of disproportionate molar ratios of PO43− and NH4+, presence of calcium and the apparent mineralisation of organic N, resulted in co-precipitation of hydroxyapatite and elevated levels of residual aqueous NH4+. In the second phase of this study, struvite was successfully precipitated and NH4+ removal was improved (~17%) however, higher concentrations of calcium in the wastewater blends resulted in greater hydroxyapatite co-precipitation (up to 30%). While struvite was the desired product in this study the formation of multiple heterogenous P-rich products (struvite and hydroxyapatite) has the potential to improve P recovery from dairy processing wastewaters and produce a fertiliser blend with amenity and value in agricultural systems. [ABSTRACT FROM AUTHOR]

The recovery of phosphorus (P) from milk processing flotation sludges (MFS) using pyrolysis can contribute to a sustainable reuse of P by converting waste to fertiliser. The objectives of this study were to quantify the recovery and transformation of P following MFS pyrolysis and compare the efficacy of raw and pyrolysed MFS as organic P fertilisers. Phosphorus retention in biochars was high (98 ± 0.73% yield), leading to the enrichment of P relative to the raw MFS by a factor of 4.3–4.5. Pyrolysis of the MFS at 450 °C led to a 3-fold increase in the proportion of P in the HCl-extractable fraction (65 ± 0.32%), a 2-fold reduction in NaOH-P (30 ± 2.1%), and negligible amounts of P in the H2O-P and NaHCO3-P fractions. The bioavailability of P in raw MFS and 450 °C biochar was compared to a soluble P fertiliser in P-limiting plant bioassays. In the short-term (70 day) trial where ryegrass was grown on three soil types (Arenosol, Vertisol or Ferralsol), biochar MFS showed higher efficacy as a P fertiliser than raw MFS in the acidic Ferralsol, whereas the opposite response was observed in the near-neutral Arenosol. In the Vertisol, neither the raw MFS nor biochar produced more cumulative biomass or P uptake than any of the nil P controls. Over a longer 200-day period, raw MFS and biochar applied to the Arenosol were about 20% as efficient at providing P to ryegrass plants as the water-soluble K2PO4, suggesting that higher application rates of MFS or biochar would be required to match synthetic fertilisers in the short term. [ABSTRACT FROM AUTHOR]

Background and aims: Hydrothermal carbonisation (HTC) is an alternative thermochemical method for conversion of waste to carbonised material. HTC converts high moisture biomass into hydrochar, with substantially lower energy inputs than pyrolysis since pre-drying is not required. Hydrochar is increasingly being proposed as a soil amendment; however, hydrochar addition to soils has inconsistent effects on germination and plant growth. Here, we aggregated hydrochar-plant studies to ascertain the effect of hydrochar on plant production. Method: Using meta-analysis, data from 43 published articles with 437 pairwise comparisons was synthesised to investigate the effect of hydrochar on seed germination or plant growth, and the driving factors. Results: On average, hydrochar application significantly reduced both seed germination (-38 %) and shoot biomass (-10 %) across hydrochar properties and experimental conditions. Negative impacts of hydrochar on seed germination and shoot biomass were greatest when application rates of hydrochar were above 11 t/ha (for all feedstocks except woody biomass) and 16 t/ha, respectively. At a standardised application rate of 10 t/ha, unmodified sewage sludge, animal manure and green waste hydrochars had a significant negative effect on germination, whilst food waste and woody hydrochars had no effect. Importantly, modification of hydrochar to lower toxin content significantly mitigated the negative effect on both shoot biomass and germination. Conclusions: Findings provide a basis for further research to elucidate mechanisms leading to the different plant responses following hydrochar application. Fundamentally, interactions among hydrochar dose, properties and edaphic variables are essential to understand when and where benefits may be achieved. [ABSTRACT FROM AUTHOR]

Security vulnerability in third-party dependencies is a growing concern not only for developers of the affected software, but for the risks it poses to an entire software ecosystem, e.g., Heartbleed vulnerability. Recent studies show that developers are slow to respond to the threat of vulnerability, sometimes taking four to eleven months to act. To ensure quick adoption and propagation of a release that contains the fix (fixing release), we conduct an empirical investigation to identify lags that may occur between the vulnerable release and its fixing release (package-side fixing release). Through a preliminary study of 231 package-side fixing release of npm projects on GitHub, we observe that a fixing release is rarely released on its own, with up to 85.72% of the bundled commits being unrelated to a fix. We then compare the package-side fixing release with changes on a client-side (client-side fixing release). Through an empirical study of the adoption and propagation tendencies of 1,290 package-side fixing releases that impact throughout a network of 1,553,325 releases of npm packages, we find that stale clients require additional migration effort, even if the package-side fixing release was quick (i.e., package-side fixing releasetypeSpatch). Furthermore, we show the influence of factors such as the branch that the package-side fixing release lands on and the severity of vulnerability on its propagation. In addition to these lags we identify and characterize, this paper lays the groundwork for future research on how to mitigate propagation lags in an ecosystem. [ABSTRACT FROM AUTHOR]

Build systems are an essential part of modern software projects. As software projects change continuously, it is crucial to understand how the build system changes because neglecting its maintenance can, at best, lead to expensive build breakage, or at worst, introduce user-reported defects due to incorrectly compiled, linked, packaged, or deployed official releases. Recent studies have investigated the (co-)evolution of build configurations and reasons for build breakage; however, the prior analysis focused on a coarse-grained outcome (i.e., either build changing or not). In this paper, we present BuildDiff, an approach to extract detailed build changes from Maven build files and classify them into 143 change types. In a manual evaluation of 400 build-changing commits, we show that BuildDiff can extract and classify build changes with average precision, recall, and f1-scores of 0.97, 0.98, and 0.97, respectively. We then present two studies using the build changes extracted from 144 open source Java projects to study the frequency and time of build changes. The results show that the top-10 most frequent change types account for 51% of the build changes. Among them, changes to version numbers and changes to dependencies of the projects occur most frequently. We also observe frequently co-occurring changes, such as changes to the source code management definitions, and corresponding changes to the dependency management system and the dependency declaration. Furthermore, our results show that build changes frequently occur around release days. In particular, critical changes, such as updates to plugin configuration parts and dependency insertions, are performed before a release day. The contributions of this paper lay in the foundation for future research, such as for analyzing the (co-)evolution of build files with other artifacts, improving effort estimation approaches by incorporating necessary modifications to the build system specification, or automatic repair approaches for configuration code. Furthermore, our detailed change information enables improvements of refactoring approaches for build configurations and improvements of prediction models to identify error-prone build files. [ABSTRACT FROM AUTHOR]

As dairy industries increase across Australia, the amount of dairy waste is also on the rise. Australia annually production stands at around 377 727 t of cheese, 273 425 t of milk powder and 92 698 t of butter, and it is the third largest exporter of milk. The waste produced by these industries is considered a potentially valuable resource, and an environmental pollutant if not appropriately managed. The focus of this review is to evaluate the potential of converting typical Australian dairy industry waste into sustainable energy. Five fundamental methods including transesterification, pyrolysis, anaerobic digestion, steam reforming, and hydrothermal carbonization are discussed. Their technological merits, demerits and adaptability from the perspective of Australia are examined. The properties of representative wastes are also considered for the different energy conversion processes. This review aims to highlight the potential use of dairy industry wastes as feedstock for the emerging renewable energy sector. © 2020 Society of Chemical Industry and John Wiley & Sons, Ltd [ABSTRACT FROM AUTHOR]

Cotton gin trash (CGT), a waste product of cotton gins, make up about 10% of each bale of cotton bolls ginned. The current study investigates high value volatile compounds in CGT to add value to this by-product. The volatile compounds in CGT and different parts of the cotton plant were extracted using various methods, identified by gas chromatography-mass spectrometry (GC-MS) or nuclear magnetic resonance (NMR) spectroscopy, and then quantified by gas chromatography-flame ionisation detection (GC-FID) against available standards. Terpenoids including monoterpenoids and sesquiterpenoids were found to be the most abundant, making up 64.66% (area under peak) of total volatiles extracted by hydro-distillation. The major extractable terpenoids in CGT were α-pinene (13.69–23.05 μg/g), β-caryophyllene (3.99–74.32 μg/g), α-humulene (2.00–25.71 μg/g), caryophyllene oxide (41.50–102.08 μg/g) and β-bisabolol (40.05–137.32 μg/g). Recoveries varied between different extraction methods. The terpenoids were found to be more abundant in the calyx (659.12 μg/g) and leaves (627.72 μg/g) than in stalks (112.97 μg/g) and stems (24.24 μg/g) of the cotton plant, indicating the possible biological origin of CGT volatiles. This study is the first to identify and quantify the different terpenoids present in CGT and significantly, β-bisabolol, an abundant compound (sesquiterpene alcohol) which may have valuable biological prospects. These findings therefore contribute to identifying alternative management strategies and uses of CGT. [ABSTRACT FROM AUTHOR]

The release frequency of software projects has increased in recent years. Adopters of so-called rapid releases—short release cycles, often on the order of weeks, days, or even hours—claim that they can deliver fixed issues (i.e., implemented bug fixes and new features) to users more quickly. However, there is little empirical evidence to support these claims. In fact, our prior work shows that code integration phases may introduce delays for rapidly releasing projects—98% of the fixed issues in the rapidly releasing Firefox project had their integration delayed by at least one release. To better understand the impact that rapid release cycles have on the integration delay of fixed issues, we perform a comparative study of traditional and rapid release cycles. Our comparative study has two parts: (i) a quantitative empirical analysis of 72,114 issue reports from the Firefox project, and a (ii) qualitative study involving 37 participants, who are contributors of the Firefox, Eclipse, and ArgoUML projects. Our study is divided into quantitative and qualitative analyses. Quantitative analyses reveal that, surprisingly, fixed issues take a median of 54% (57 days) longer to be integrated in rapid Firefox releases than the traditional ones. To investigate the factors that are related to integration delay in traditional and rapid release cycles, we train regression models that model whether a fixed issue will have its integration delayed or not. Our explanatory models achieve good discrimination (ROC areas of 0.80-0.84) and calibration scores (Brier scores of 0.05-0.16) for rapid and traditional releases. Our explanatory models indicate that (i) traditional releases prioritize the integration of backlog issues, while (ii) rapid releases prioritize issues that were fixed in the current release cycle. Complementary qualitative analyses reveal that participants’ perception about integration delay is tightly related to activities that involve decision making, risk management, and team collaboration. Moreover, the allure of shipping fixed issues faster is a main motivator for adopting rapid release cycles among participants (although this motivation is not supported by our quantitative analysis). Furthermore, to explain why traditional releases deliver fixed issues more quickly, our participants point out the rush for integration in traditional releases and the increased time that is invested on polishing issues in rapid releases. Our results suggest that rapid release cycles may not be a silver bullet for the rapid delivery of new content to users. Instead, our results suggest that the benefits of rapid releases are increased software stability and user feedback. [ABSTRACT FROM AUTHOR]

Predicting the required time to fix an issue (i.e., a new feature, bug fix, or enhancement) has long been the goal of many software engineering researchers. However, after an issue has been fixed, it must be integrated into an official release to become visible to users. In theory, issues should be quickly integrated into releases after they are fixed. However, in practice, the integration of a fixed issue might be prevented in one or more releases before reaching users. For example, a fixed issue might be prevented from integration in order to assess the impact that this fixed issue may have on the system as a whole. While one can often speculate, it is not always clear why some fixed issues are integrated immediately, while others are prevented from integration. In this paper, we empirically study the integration of 20,995 fixed issues from the ArgoUML, Eclipse, and Firefox projects. Our results indicate that: (i) despite being fixed well before the release date, the integration of 34% to 60% of fixed issues in projects with traditional release cycle (the Eclipse and ArgoUML projects), and 98% of fixed issues in a project with a rapid release cycle (the Firefox project) was prevented in one or more releases; (ii) using information that we derive from fixed issues, our models are able to accurately predict the release in which a fixed issue will be integrated, achieving Areas Under the Curve (AUC) values of 0.62 to 0.93; and (iii) heuristics that estimate the effort that the team invests to fix issues is one of the most influential factors in our models. Furthermore, we fit models to study fixed issues that suffer from a long integration time. Such models, (iv) obtain AUC values of 0.82 to 0.96 and (v) derive much of their explanatory power from metrics that are related to the release cycle. Finally, we train regression models to study integration time in terms of number of days. Our models achieve R2 values of 0.39 to 0.65, and indicate that the time at which an issue is fixed and the resolver of the issue have a large impact on the number of days that a fixed issue requires for integration. Our results indicate that, in addition to the backlog of issues that need to be fixed, the backlog of issues that need to be released introduces a software development overhead, which may lead to a longer integration time. Therefore, in addition to studying the triaging and fixing stages of the issue lifecycle, the integration stage should also be the target of future research and tooling efforts in order to reduce the time-to-delivery of fixed issues. [ABSTRACT FROM AUTHOR]

Software developers rely on a build system to compile their source code changes and produce deliverables for testing and deployment. Since the full build of large software systems can take hours, the incremental build is a cornerstone of modern build systems. Incremental builds should only recompile deliverables whose dependencies have been changed by a developer. However, in many organizations, such dependencies still are identified by build rules that are specified and maintained (mostly) manually, typically using technologies like make. Incomplete rules lead to unspecified dependencies that can prevent certain deliverables from being rebuilt, yielding incomplete results, which leave sources and deliverables out-of-sync. In this paper, we present a case study on unspecified dependencies in the make-based build systems of the glib, openldap, linux and qt open source projects. To uncover unspecified dependencies in make-based build systems, we use an approach that combines a conceptual model of the dependencies specified in the build system with a concrete model of the files and processes that are actually exercised during the build. Our approach provides an overview of the dependencies that are used throughout the build system and reveals unspecified dependencies that are not yet expressed in the build system rules. During our analysis, we find that unspecified dependencies are common. We identify 6 common causes in more than 1.2 million unspecified dependencies. [ABSTRACT FROM AUTHOR]

Software code review is a well-established software quality practice. Recently, Modern Code Review (MCR) has been widely adopted in both open source and proprietary projects. Our prior work shows that review participation plays an important role in MCR practices, since the amount of review participation shares a relationship with software quality. However, little is known about which factors influence review participation in the MCR process. Hence, in this study, we set out to investigate the characteristics of patches that: (1) do not attract reviewers, (2) are not discussed, and (3) receive slow initial feedback. Through a case study of 196,712 reviews spread across the Android, Qt, and OpenStack open source projects, we find that the amount of review participation in the past is a significant indicator of patches that will suffer from poor review participation. Moreover, we find that the description length of a patch shares a relationship with the likelihood of receiving poor reviewer participation or discussion, while the purpose of introducing new features can increase the likelihood of receiving slow initial feedback. Our findings suggest that the patches with these characteristics should be given more attention in order to increase review participation, which will likely lead to a more responsive review process. [ABSTRACT FROM AUTHOR]

Although cultivated for over 7000 years, mainly for production of cotton fibre, the cotton plant has not been fully explored for potential uses of its other parts. Despite cotton containing many important chemical compounds, limited understanding of its phytochemical composition still exists. In order to add value to waste products of the cotton industry, such as cotton gin trash, this review focuses on phytochemicals associated with different parts of cotton plants and their biological activities. Three major classes of compounds and some primary metabolites have been previously identified in the plant. Among these compounds, most terpenoids and their derivatives (51), fatty acids (four), and phenolics (six), were found in the leaves, bolls, stalks, and stems. Biological activities, such as anti-microbial and anti-inflammatory activities, are associated with some of these phytochemicals. For example, β-bisabolol, a sesquiterpenoid enriched in the flowers of cotton plants, may have anti-inflammatory product application. Considering the abundance of biologically active compounds in the cotton plant, there is scope to develop a novel process within the current cotton fibre production system to separate these valuable phytochemicals, developing them into potentially high-value products. This scenario may present the cotton processing industry with an innovative pathway towards a waste-to-profit solution. [ABSTRACT FROM AUTHOR]

Software developers rely on a fast build system to incrementally compile their source code changes and produce modified deliverables for testing and deployment. Header files, which tend to trigger slow rebuild processes, are most problematic if they also change frequently during the development process, and hence, need to be rebuilt often. In this paper, we propose an approach that analyzes the build dependency graph (i.e., the data structure used to determine the minimal list of commands that must be executed when a source code file is modified), and the change history of a software system to pinpoint header file hotspots-header files that change frequently and trigger long rebuild processes. Through a case study on the GLib, PostgreSQL, Qt, and Ruby systems, we show that our approach identifies header file hotspots that, if improved, will provide greater improvement to the total future build cost of a system than just focusing on the files that trigger the slowest rebuild processes, change the most frequently, or are used the most throughout the codebase. Furthermore, regression models built using architectural and code properties of source files can explain 32-57 % of these hotspots, identifying subsystems that are particularly hotspot-prone and would benefit the most from architectural refinement. [ABSTRACT FROM AUTHOR]

Unlike traditional defect prediction models that identify defect-prone modules, Just-In-Time (JIT) defect prediction models identify defect-inducing changes. As such, JIT defect models can provide earlier feedback for developers, while design decisions are still fresh in their minds. Unfortunately, similar to traditional defect models, JIT models require a large amount of training data, which is not available when projects are in initial development phases. To address this limitation in traditional defect prediction, prior work has proposed cross-project models, i.e., models learned from other projects with sufficient history. However, cross-project models have not yet been explored in the context of JIT prediction. Therefore, in this study, we empirically evaluate the performance of JIT models in a cross-project context. Through an empirical study on 11 open source projects, we find that while JIT models rarely perform well in a cross-project context, their performance tends to improve when using approaches that: (1) select models trained using other projects that are similar to the testing project, (2) combine the data of several other projects to produce a larger pool of training data, and (3) combine the models of several other projects to produce an ensemble model. Our findings empirically confirm that JIT models learned using other projects are a viable solution for projects with limited historical data. However, JIT models tend to perform best in a cross-project context when the data used to learn them are carefully selected. [ABSTRACT FROM AUTHOR]

Software code review, i.e., the practice of having other team members critique changes to a software system, is a well-established best practice in both open source and proprietary software domains. Prior work has shown that formal code inspections tend to improve the quality of delivered software. However, the formal code inspection process mandates strict review criteria (e.g., in-person meetings and reviewer checklists) to ensure a base level of review quality, while the modern, lightweight code reviewing process does not. Although recent work explores the modern code review process, little is known about the relationship between modern code review practices and long-term software quality. Hence, in this paper, we study the relationship between post-release defects (a popular proxy for long-term software quality) and: (1) code review coverage, i.e., the proportion of changes that have been code reviewed, (2) code review participation, i.e., the degree of reviewer involvement in the code review process, and (3) code reviewer expertise, i.e., the level of domain-specific expertise of the code reviewers. Through a case study of the Qt, VTK, and ITK projects, we find that code review coverage, participation, and expertise share a significant link with software quality. Hence, our results empirically confirm the intuition that poorly-reviewed code has a negative impact on software quality in large systems using modern reviewing tools. [ABSTRACT FROM AUTHOR]

The widespread deployment of commercial-scale cellulosic ethanol currently hinges on developing and evaluating scalable processes whilst broadening feedstock options. This study investigates whole Eucalyptus grandis trees as a potential feedstock and demonstrates dilute acid pre-treatment (with steam explosion) followed by pre-saccharification simultaneous saccharification fermentation process ( PSSF) as a suitable, scalable strategy for the production of bioethanol. Biomass was pre-treated in dilute H2SO4 at laboratory scale (0.1 kg) and pilot scale (10 kg) to evaluate the effect of combined severity factor ( CSF) on pre-treatment effectiveness. Subsequently, pilot-scale pre-treated residues (15 wt.%) were converted to ethanol in a PSSF process at 2 L and 300 L scales. Good polynomial correlations (n = 2) of CSF with hemicellulose removal and glucan digestibility with a minimum R2 of 0.91 were recorded. The laboratory-scale 72 h glucan digestibility and glucose yield was 68.0% and 51.3%, respectively, from biomass pre-treated at 190 °C /15 min/ 4.8 wt.% H2SO4. Pilot-scale pre-treatment (180 °C/ 15 min/2.4 wt.% H2SO4 followed by steam explosion) delivered higher glucan digestibility (71.8%) and glucose yield (63.6%). However, the ethanol yields using PSSF were calculated at 82.5 and 113 kg/ton of dry biomass for the pilot and the laboratory scales, respectively. © 2016 Society of Chemical Industry and John Wiley & Sons, Ltd [ABSTRACT FROM AUTHOR]

Build systems specify how source code is translated into deliverables. They require continual maintenance as the system they build evolves. This build maintenance can become so burdensome that projects switch build technologies, potentially having to rewrite thousands of lines of build code. We aim to understand the prevalence of different build technologies and the relationship between build technology and build maintenance by analyzing version histories in a corpus of 177,039 repositories spread across four software forges, three software ecosystems, and four large-scale projects. We study low-level, abstraction-based, and framework-driven build technologies, as well as tools that automatically manage external dependencies. We find that modern, framework-driven build technologies need to be maintained more often and these build changes are more tightly coupled with the source code than low-level or abstraction-based ones. However, build technology migrations tend to coincide with a shift of build maintenance work to a build-focused team, deferring the cost of build maintenance to them. [ABSTRACT FROM AUTHOR]

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. [ABSTRACT FROM AUTHOR]