Skandium library user. The Task keeps track, among other of the execution state, data state, exceptions, future updating, and children tasks. Children tasks are created when data parallelism is encountered.
@author mleyton
null parameter is considered ready). Should be created in the context of {@link AsyncScope#doAsync()} method, from{@link Task#doExecute()} or from {@link TryCatchFinally} do... methods.Exceptions thrown from {@link #doExecute()} are delivered asynchronously tothe wrapping {@link TryCatchFinally#doCatch(Throwable)} method or rethrownfrom {@link AsyncScope#eventLoop()} if no wrapping {@link TryCatchFinally} isfound.
Example of using {@link Task} to implement asynchronous function that sumsparameters when both of them are ready:
public Promise<Integer> sum(Promise<Integer> a, Promise<Integer> b) { Settable<Integer> result = new Settable<Integer>(); new Task(a, b) { public void doExecute() { result.set(a.get() + b.get()); } }; return result; }
@see AsyncScope
@see TryCatchFinally
@see Promise
This class represents both a task to be enqueued and a task being handled.
When enqueueing a task, construct a concrete subclass with the appropriate data, and then add the task to an {@link com.google.appengine.tools.pipeline.impl.backend.UpdateSpec} and{@link com.google.appengine.tools.pipeline.impl.backend.PipelineBackEnd#save save}. Alternatively the task may be enqueued directly using {@link com.google.appengine.tools.pipeline.impl.backend.PipelineBackEnd#enqueue(Task)}.
When handling a task, construct a {@link Properties} object containing therelevant parameters from the request, its name and then invoke {@link #fromProperties(String,Properties)}. @author rudominer@google.com (Mitch Rudominer)
This class holds the representation of a single task.
Task must also implement {@link Serializable}.
@see TaskManager
Abstract base representation of a cron4j task.
Developers can extends this abstract class to build their own tasks.
Extending Task means, above all, implementing the {@link Task#execute(TaskExecutionContext)} method. Within this method thetask must perform its operation. If the execute() method returns regularly then the execution is considered to be successfully completed. If execute() dies throwing a {@link RuntimeException} then the taskexecution is considered to be failed. The supplied parameter, which is a {@link TaskExecutionContext} instance, helps the developer in integrating histask with the scheduler executor. Through the context the developer can check if the execution has been paused or stopped, and he can also push back some status informations by calling {@link TaskExecutionContext#setCompleteness(double)} and{@link TaskExecutionContext#setStatusMessage(String)}.
If the custom task supports pausing, stopping and/or tracking, that should be notified by overriding {@link Task#canBePaused()}, {@link Task#canBeStopped()}, {@link Task#supportsCompletenessTracking()}and/or {@link Task#supportsStatusTracking()}.
@author Carlo Pelliccia @since 2.0Task can be started at a given time in the future and can be a daemon. The block of code will be passed a Log object each time it is run through its ICode interface. If the code block takes longer than the period to run, the next task invocation will occur immediately. In this case, tasks will not occur at precise multiples of the period. For example, if you run a task every 30 seconds, and the first run takes 40 seconds but the second takes 20 seconds, your task will be invoked at 0 seconds, 40 seconds and 70 seconds (40 seconds + 30 seconds), which is not an even multiple of 30 seconds.
In general, this is a simple task class designed for polling activities. If you need precise guarantees, you probably should be using a different task class. @author Jonathan Locke @since 1.2.6
execute must return {@link Outcome#STEP_COMPLETE}, {@link Outcome#STEP_CONTINUE} or{@link Outcome#STEP_ABORT}. Subclasses can add any errors by calling the helper method {@link AbstractStep#addError(String)}. The execute method should generally capture and add errors to the error list instead of throwing a WikiException. @since 2.5
A Task represents a single atomic piece of work for a build, such as compiling classes or generating javadoc.
Each task belongs to a {@link Project}. You can use the various methods on {@link org.gradle.api.tasks.TaskContainer} to create and lookup task instances. For example, {@link org.gradle.api.tasks.TaskContainer#add(String)} creates an empty task with the given name. You can also use the{@code task} keyword in your build file:
task myTask task myTask { configure closure } task myType << { task action } task myTask(type: SomeType) task myTask(type: SomeType) { configure closure } Each task has a name, which can be used to refer to the task within its owning project, and a fully qualified path, which is unique across all tasks in all projects. The path is the concatenation of the owning project's path and the task's name. Path elements are separated using the {@value org.gradle.api.Project#PATH_SEPARATOR}character.
A Task is made up of a sequence of {@link Action} objects. When the task is executed, each of theactions is executed in turn, by calling {@link Action#execute}. You can add actions to a task by calling {@link #doFirst(Action)} or {@link #doLast(Action)}.
Groovy closures can also be used to provide a task action. When the action is executed, the closure is called with the task as parameter. You can add action closures to a task by calling {@link #doFirst(groovy.lang.Closure)} or{@link #doLast(groovy.lang.Closure)} or using the left-shift << operator.
There are 2 special exceptions which a task action can throw to abort execution and continue without failing the build. A task action can abort execution of the action and continue to the next action of the task by throwing a {@link org.gradle.api.tasks.StopActionException}. A task action can abort execution of the task and continue to the next task by throwing a {@link org.gradle.api.tasks.StopExecutionException}. Using these exceptions allows you to have precondition actions which skip execution of the task, or part of the task, if not true.
A task may have dependencies on other tasks. Gradle ensures that tasks are executed in dependency order, so that the dependencies of a task are executed before the task is executed. You can add dependencies to a task using {@link #dependsOn(Object)} or {@link #setDependsOn(Iterable)}. You can add objects of any of the following types as a dependency:
A {@code Task} has 3 'scopes' for properties. You can access these properties by name from the build file or bycalling the {@link #property(String)} method.
A {@link Plugin} may add methods to a {@code Task} using its {@link Convention} object.
@author Hans DockterCopyright (C) 2011-2013 Carlos Eduardo Leite de Andrade
This library is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public License along with this program. If not, see www.gnu.org/licenses/
For more information, contact: www.japura.org
@author Carlos Eduardo Leite de Andrade
<xs:complexType name="TaskType">TODO: this object and the hierarchy is wrong. it is literally a Task with a Task container. please review class diagram @author grkvlt@apache.org
A Task is some kind of long running action that should be done in the background. The task can update the progress based on the current position in the workload.
Basically what you have to do for your own Task is to override the run() method and frequently call one of the updateProgress methods.
@author Christopher Hlubek (hlubek)The following features are supported:
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |