Software architecture analysis of Gradle

(Bij) #1

Dear developers and contributors,

We are four computer science students at Delft University of Technology in the Netherlands, doing a course on Software Architecture. The main project of this course consists of an in-depth analysis of open source project. Due to our interest in your build tool we have decided to do this analysis on the Gradle build tool. The end product will be a chapter for the book: Delft Students On Software Architecture 2017 (For older versions, check:

Our progress so far includes the identification of different stakeholders, the generation of a context view and an elaboration on the development view which are based on the Software Architecture book written by Rozanski and Woods. The next part of our project will focus on the identification of technical and testing debt.

The definition of technical debt that is used: “Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution”.

In order to get a more thorough understanding of how these aspects are treated by the Gradle developers, we were hoping that we could ask a few questions:

  1. Could you elaborate on the file structure of the Gradle Github repository e.g. it seems that the core of the Gradle software is located in the sub-projects folder. Why is to structure the repository in such a way and do you have any thoughts on how you might change this in the future?

  2. It would be very interesting to see how the design of Gradle has evolved over time. We have attempted to piece together information from the design-docs folder but were also wondering whether a more general design plan has been created?

  3. The importance of testing to Gradle becomes apparent when analysing for example the contribution file on Github. Do you think that your current testing approach can be improved upon by using different testing techniques or elaborating the current test suite? Do you consider some parts of the project to be under tested which could be classified as testing debt?

  4. During the evolution of Gradle, have the main goals of the Gradle platform and its functions changed as compared to its original design? Have unexpected changes caused any incurred technical debt, leaving code unchanged when adaptations would have been desired for long-term performance?

  5. What are the advantages of using Spock as compared to using jUnit in your specific case? Why do you not use the latter as it seems to be the standard choice for many other projects?

It would mean a lot to our learning experience if you could provide us with some information on your view of the system. If anything is unclear, do not hesitate to contact us. In addition, if you or your colleagues might want to receive our final product we would be more than happy to share our chapter of the book.

Thank you very much for your time and effort!

Kind regards,

Hugo Bijmans
Lars van de Kamp
Julian Hols
Ingmar Wever