Yes, the files you usually see similar to the code above are the compilation configuration of gradle. To put it simply, there are not many places where groovy and program flow are shown, so it is difficult for ordinary people to understand why a language is like this (this is why it is called a DSL).
Of course, gradle can also write many compilation process control method tasks, but generally they are written in the integrated environment and are not reflected.
In addition, in the above code, jar is an object, manifest is its attribute, and it is also an object, and contains the attributes attribute
Yes, the files you usually see similar to the code above are the compilation configuration of gradle. To put it simply, there are not many places where groovy and program flow are shown, so it is difficult for ordinary people to understand why a language is like this (this is why it is called a DSL).
Of course, gradle can also write many compilation process control method tasks, but generally they are written in the integrated environment and are not reflected.
In addition, in the above code, jar is an object, manifest is its attribute, and it is also an object, and contains the attributes attribute
DSL is a concept, not a specific language.
You understand it this way, Gradle is a tool specifically used for project construction, and the build script it uses is a DSL based on groovy.
I think the syntax you mentioned should not be understood as objects and fields:
Because gradle is a build tool, it is better to understand it as [task/task configuration]:
jar: Generate a jar package
manifest: The manifest file in the jar package, telling the java virtual machine MainClass.