bugﬁxes Became committer in 2011 Contributed a number of things mostly around DSL and compile-time metaprogramming: - AST transformations - Static type checker and static compilation (@CompileStatic) - Traits - Type checking extensions - Template engine with static compilation of templates
(17 years old!) Started with Apache Ant Attempt to migrate to Apache Maven but never ﬁnished/too complicated Gradle introduced in 2008 as a parallel build Really usable in 2012 after the Gradle 1.0 release This is where I started to contribute to the build
working Gradle build, including build cache, but: ⬢ Written by many different people ⬢ With “conventions” inherited from older build tools (Ant, Maven) ⬢ With very old releases of Gradle ◦ Many things were harder to do back then ◦ Many outdated patterns ◦ Accidental dependencies ◦ Lack of guidance ◦ ...
(GAV) coordinates: - From org.codehaus.groovy to org.apache.groovy Removal of the classic ﬂavor Gradle 7 Removes the old “maven” plugin in favor of “maven-publish” Ideal to leverage some of the dependency management features introduced in Gradle 6!
“main” project: it’s a library, but also provides the Groovy compiler itself Groovy modules JSON support, Date utils, Template engines, … Aggregating projects Groovy “all” (which isn’t Groovy all but a subset of Groovy + Groovy modules) The BOM The distribution Utilities (stress tests, …)
- hard to tell what this script is about. Hard to ﬁgure out where to make modiﬁcations. “Magic” going on. ⬢ Explicit task creation - Duplicated code between modules. Hardcoded task name ⬢ Explicit task dependency - and wrong! ⬢ How do you know it’s part of groovy-all?
build script readable ⬢ They talk about the what and they abstract the how ⬢ Creates tasks if needed A build script just applies the plugin and configures the extension The extension does the “hard work”
E.g “dependsOn rootProject.task(“jar”) This is fragile, unsafe and it breaks encapsulation. Was challenging with the Groovy build which abused reaching out to other projects everywhere. https://docs.gradle.org/current/userguide/cross_project_publications.html
- Based on the deprecated publication mechanisms (maven plugin) - Used a lot of internal APIs - Made lots of customizations to the generated POM ﬁles - Because of relocated dependencies - Because of the multiple ﬂavors
of all internal APIs - Publishes Gradle Module Metadata - Running `./gradlew publish` generates a local repository in `build/repo` which allows seeing what is going to be published Gradle Module Metadata beneﬁts: - Users will get an error if they use both the old Groovy (Codehaus) and new Groovy (Apache) - They can depend on optional features and get the dependencies they need automatically - They get automatic version alignment for free!
compiling with a JDK, running/testing with another in a declarative manner - Automatic download of JDK! - Removes the need for special tweaks in the build depending on what is used to run Gradle itself But… - Requires Gradle 6.8 for Groovy compilation support - Requires changes to the build pipeline (but it makes it simpler!)
- groovy-core should become a subproject itself - Allows moving some remaining shared conﬁguration to where it belongs Remove old Ant tasks - Some tasks like `jarjar` still depend on very old Ant tasks - May require some extra work from Gradle