On 23/04/2013, at 6:23 AM, Patrick van Dissel <[email protected]> wrote:
> Hi, > > I'm looking for someone or some document who/which can give me an in-depth > overview of the Gradle internal workings. > > I'm interested on how Gradle works internally, from front to back, incl. the > GroovyDSL implementation, the abstractions, factories, CLI UI output, etc. > > I've already read through most of the launcher, core and plugin code. Trying > to learn from the gradle implementation. On one side I find the code > fascinatingly clean and separated/abstract. but on the other side I'm missing > the link between the abstraction and how it's working at runtime. Looking at the code is probably the best option. There's no overview documentation of the internals of Gradle at the moment, so the code is the only documentation. You're welcome to ask any questions you have about Gradle internals on the dev list or on the forums and we'll try to help out. > > I know gradleware provides Gradle In-Depth trainings, but those are trainings > about how to use gradle from the outside as far as I understand from the > description like: > http://www.gradleware.com/products/training/live/gradle-depth > I'm more interested in the internal workings of gradle. The training courses don't cover any of the internals of Gradle, only the publicly visible stuff. > > Why I'm interested in the internals? > Two reasons: > 1. I'm building a open-source Continuous Integration server, which uses > practices that Gradle uses but then on a CI level. Gradle, Maven, make, etc, > are still needed to build the specific projects. > I think my wiki page explains it best, why I want to build another CI tool > and what I want to do better: > https://github.com/pvdissel/cy.io/wiki/Why-a-new-CI-tool > https://github.com/pvdissel/cy.io/wiki/Global-design (DSL ideas) > So I want to learn the Gradle internals, so I can use the same > implementation ideas/ways in my tool. I can even see my tool as an extension > of Gradle :D My CI tool managing the project release pipelines while gradle > is used for the project specific automation and building. It's an interesting idea. > > Note "cy.io" is a temporary name and the project is still in early > development. During the DevOpsDays Amsterdam conference > (http://www.devopsdays.org/events/2013-amsterdam/) on June 14-15 I want to > throw my ideas into the world with an Ignite talk and an Open-Space > discussion on what people think of my ideas and I would like to discuss > implementation details with them. To see what the next steps could be. > > 2. I would love to help out on Gradle development. I found the contribute > list on: > http://www.gradle.org/contribute > But also for those, I think it would be good to have knowledge of the > internal working of Gradle. Usually, if you let us know that you want to work on, we'll put together a design document that will help you find your way through the internals. So, no knowledge of the internals is required to get started with contributions. Do you have some specific things you are interested in working on? -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com
