inside the gradle.build what this type i tried to get the class but it output build_6ineg7nk53oil05rsnh0evd1j but i can not find the build class in the javadoc api
so which type this represent
using the command line gradle it run the task that start with this taskname it does not check if the full name match
so for example
final Project currentProject = getProject()
final TaskContainer taskContainer = currentProject.getTasks()
final TaskProvider<Task> testTask = taskContainer.register("test")
testTask.get().doLast(action -> System.out.println("This is executed during the execution phase."))
running the following command
gradle test
gradle te
gradle tes
all make the test task run the only one that does not work
does that mean gradle run the closest task to the given name and if yes could i get how it pick task
i also notice it do the same for gradle ta and gradle tas both run gradle task
No, the script is compiled to a class that represents the script and that is the type of this.
But most things will be forwarded to an instance of Settings.
Just like with Project for build scripts and Gradle for init scripts.
inside the gradle.build what this type i tried to get the class but it output build_6ineg7nk53oil05rsnh0evd1j but i can not find the build class in the javadoc api
so which type this represent
See above
final TaskProvider<Task> testTask = taskContainer.register("test")
testTask.get().doLast(action -> System.out.println("This is executed during the execution phase."))
There is not much sense in using the task configuration avoidance api (taskContainer.register) if you right away use get() and thus cause the task to be realized immediately.
Either use configure(...) or give a configuration closuer directly with the register call.
all make the test task run the only one that does not work
Is this sentence incomplete?
Is there for example “is t” missing or so?
does that mean gradle run the closest task to the given name and if yes could i get how it pick task
If what you give is an excat name, it is used, otherwise if the part you give is able to uniquely identify a task, it is run, otherwise it tells you that it is ambiguous and tells you which task names do match. It also understands camelCase like aBC for anotherBetterCodetask.
i also notice it do the same for gradle ta and gradle tas both run gradle task
No, it runs the tasks, not task, unless there is also a task task, then it will complain.
this.getRootProject().setName("basic")
System.out.println("This is executed during the initialization phase.")
for build.gradle
System.out.println("This is executed during the configuration phase.")
final Project currentProject = getProject()
final TaskContainer taskContainer = currentProject.getTasks()
final TaskProvider<Task> configuredTask = taskContainer.register("configured", action ->
System.out.println("This is also executed during the configuration phase, because :configured is used in the build.")
)
final TaskProvider<Task> testTask = taskContainer.register("test")
testTask.get().doLast(action -> System.out.println("This is executed during the execution phase."))
final TaskProvider<Task> testBothTask = taskContainer.register("testBoth", action ->
System.out.println("This is executed during the configuration phase as well, because :testBoth is used in the build."))
testBothTask.get().doFirst(action -> System.out.println("This is executed first during the execution phase."))
testBothTask.get().doLast(action -> System.out.println("This is executed last during the execution phase."))
each time i click on closure the site send me to groovy api page
sorry my bad meant that all run test task except when call gradle t
As long as you are within build.gradle or settings.gradle, you are not writing Java code, you are writing Groovy code.
Groovy aimes to be the scripting language alongside of Java and thus usually supports most Java language constructs, so you can write Groovy code that majorly looks ike Java code.
But you are still writing Groovy code.
And Groovy is a highly dynamic language with duck-typing and delegating and many magic things.
If you call getRootProject() on this it is not actually served by the script instance itself, but forwareded to the delegate of that script, so a Settings instance for the settings script, a Plugin instance for the build script, a Gradle instance for an init script.
So? Closure is a Groovy class.
But there are usually also variants that take Action which you can give as Java lambda.
That syntax is Groovy syntactic sugar to supply a Map with two entries.
So if you would use Java syntax, you would build the map and give that to the method.
Accessing the ant property from Groovy results in getAnt() being called. This returns an AntBuilder. AntBuilder uses the dynamic features of Groovy to allow Ant tasks to be called as methods. Since these Ant task methods are dynamic they do not appear in any JavaDoc.
While Chris is right and this again is much Groovy black magic that you should not really try to Java-syntaxify, you can do things like project.getAnt().invokeMethod("loadfile", mapWithTheArguments).
final TaskContainer taskContainer = getProject().getTasks()
final Task taskX = taskContainer.register("taskX").get()
/* if you tried to add the
taskX.dependsOn(taskY)
or
taskX.dependsOn(taskContainer.getByName("taskY"))
both will not work
not sure if there another way or not
but the next one is a work around
/
taskContainer.whenTaskAdded(task -> {
if (((Task) task).getName().equals("taskY")) {
taskX.dependsOn(task)
}
})
taskX.doLast(task -> System.out.println("taskX"))
final Task taskY = taskContainer.register("taskY").get()
taskY.doLast(task -> System.out.println("taskY"))
does that mean java code could affect the code capability or i miss something
thanks again for all your time and help and sorry for sending million of question can not promise i will stop posting questions
While again it is ridiculous to use task configuration avoidance API (register) and then immediately querying the provider with get instead of working with the provider, completely destroying task configuration avoidance, why so complicated? If you want example in Java syntax, just do it. taskX.dependsOn("taskY").
I personally don’t like the depending by String way too much, but it works the same with Java-like syntax.
Actually almost any explicit task dependency is bad except for lifecycle tasks.
