You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Overhaul script plugins as convention plugins #12258
Replace gradle/*.gradle script plugins and their dynamic APIs with focused convention
plugins.
Modules declare their role through dd-trace-java.module.*; those plugins compose the
capabilities they need.
Move reusable build logic from buildSrc to the included build-logic
build as each composition becomes independent of the remaining scripts. Preserve build behaviour
and migrate one concern at a time.
Motivation
The legacy script plugins have a few issues:
The current scripts share configuration through apply from, ext.* properties and Groovy closures. This is discouraged now from gradle best practices, and slowly phased out, and groovy causes maintenance problems as it is not typed.
Their dependencies and application order are implicit, and consumers lack typed APIs for compiler settings, test suites and coverage.
Broad Java defaults also attach capabilities to modules that do not use them.
Convention plugins give each capability a stable ID, a clear owner and independently testable behaviour. Kotlin exposes API mistakes during compilation and improves IDE navigation. Module conventions make each project's purpose visible and let future distributions compose only the build behaviour they need.
Moving to build-logic gives build tooling an explicit dependency graph and its own build and
test lifecycle. It reduces reliance on the implicit shared buildSrc classpath and allows
standalone builds to reuse plugins. This supports configuration-cache and project-isolation work;
those benefits still require lazy task wiring, declared inputs and outputs, and removal of
cross-project configuration.
Activity
[-]Migration to convention plugins[/-][+]Overhaul script plugins as convention plugins[/+]