Move common tasks up in CLI docs

Move common tasks up in CLI docs

Fixes gradle/dotorg-docs#155

Signed-off-by: Eric Wendelin <96f164ad4d9b2b0dacf8ebee2bb1eeb3aa69adf1@gradle.com>

// Copyright 2017 the original author or authors.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//      http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

[[command_line_interface]]
== Command-Line Interface

[.lead]
The command-line interface is one of the primary methods of interacting with Gradle. The following serves as a reference of executing and customizing Gradle use of a command-line or when writing scripts or configuring continuous integration.

Use of the <<gradle_wrapper, Gradle Wrapper>> is highly encouraged. You should substitute `./gradlew` or `gradlew.bat` for `gradle` in all following examples when using the Wrapper.

Executing Gradle on the command-line conforms to the following structure. Options are allowed before and after task names.
----
gradle [taskName...] [--option-name...]
----

If multiple tasks are specified, they should be separated with a space.

Options that accept values can be specified with or without `=` between the option and argument; however, use of `=` is recommended.
----
--console=plain
----

Options that enable behavior have long-form options with inverses specified with `--no-`. The following are opposites.
----
--build-cache
--no-build-cache
----

Many long-form options, have short option equivalents. The following are equivalent:
----
--help
-h
----

[NOTE]
====
Many command-line flags can be specified in `gradle.properties` to avoid needing to be typed. See the <<sec:gradle_configuration_properties, configuring build environment guide>> for details.
====

The following sections describe use of the Gradle command-line interface, grouped roughly by user goal. Some plugins also add their own command line options, for example <<test_filtering,`--tests` for Java test filtering>>.

[[sec:command_line_executing_tasks]]
=== Executing tasks

You can run a task and all of its dependencies.
----
❯ gradle myTask
----

You can learn about what projects and tasks are available in the <<sec:command_line_project_reporting, project reporting section>>.

==== Executing tasks in multi-project builds
In a <<intro_multi_project_builds, multi-project build>>, subproject tasks can be executed with ":" separating subproject name and task name. The following are equivalent _when run from the root project_.

----
❯ gradle :mySubproject:taskName
❯ gradle mySubproject:taskName
----

You can also run a task for all subprojects using the task name only. For example, this will run the "test" task for all subprojects when invoked from the root project directory.

----
❯ gradle test
----

When invoking Gradle from within a subproject, the project name should be omitted:

----
❯ cd mySubproject
❯ gradle taskName
----

[NOTE]
====
When executing the Gradle Wrapper from subprojects, one must reference `gradlew` relatively. For example: `../gradlew taskName`. The community http://www.gdub.rocks/[gdub project] aims to make this more convenient.
====

==== Executing multiple tasks
You can also specify multiple tasks. For example, the following will execute the `compile` and `test` tasks in the order that they are listed on the command-line and will also execute the dependencies for each task.

----
❯ gradle compile test
----

[[sec:excluding_tasks_from_the_command_line]]
==== Excluding tasks from execution
You can exclude a task from being executed using the `-x` or `--exclude-task` command-line option and providing the name of the task to exclude.

++++
<figure>
    <title>Example Task Graph</title>
    <imageobject>
        <imagedata fileref="img/commandLineTutorialTasks.png"/>
    </imageobject>
</figure>
++++

++++
<sample id="excludeTask" dir="userguide/tutorial/excludeTasks" title="Excluding tasks">
    <output args="dist --exclude-task test"/>
</sample>
++++

You can see that the `test` task is not executed, even though it is a dependency of the `dist` task. The `test` task's dependencies such as `compileTest` are not executed either. Those dependencies of `test` that are required by another task, such as `compile`, are still executed.

[[sec:rerun_tasks]]
==== Forcing tasks to execute

You can force Gradle to execute all tasks ignoring <<sec:up_to_date_checks,up-to-date checks>> using the `--rerun-tasks` option:

----
❯ gradle test --rerun-tasks
----

This will force `test` and _all_ task dependencies of `test` to execute. It's a little like running `gradle clean test`, but without the build's generated output being deleted.

[[sec:continue_build_on_failure]]
==== Continuing the build when a failure occurs

By default, Gradle will abort execution and fail the build as soon as any task fails. This allows the build to complete sooner, but hides other failures that would have occurred. In order to discover as many failures as possible in a single build execution, you can use the `--continue` option.

----
❯ gradle test --continue
----

When executed with `--continue`, Gradle will execute _every_ task to be executed where all of the dependencies for that task completed without failure, instead of stopping as soon as the first failure is encountered. Each of the encountered failures will be reported at the end of the build.

If a task fails, any subsequent tasks that were depending on it will not be executed. For example, tests will not run if there is a compilation failure in the code under test; because the test task will depend on the compilation task (either directly or indirectly).

=== Common tasks

The following are task conventions applied by built-in and most major Gradle plugins.

==== Computing all outputs

It is common in Gradle builds for the `build` task to designate assembling all outputs and running all checks.

----
❯ gradle build
----

==== Running applications

It is common for applications to be run with the `run` task, which assembles the application and executes some script or binary.

----
❯ gradle run
----

==== Running all checks

It is common for _all_ verification tasks, including tests and linting, to be executed using the `check` task.

----
❯ gradle check
----

==== Cleaning outputs

You can delete the contents of the build directory using the `clean` task, though doing so will cause pre-computed outputs to be lost, causing significant additional build time for the subsequent task execution.

----
❯ gradle clean
----

[[sec:command_line_completion]]
=== Command-Line completion

Gradle provides bash and zsh tab completion support for tasks, options, and Gradle properties through https://github.com/gradle/gradle-completion[gradle-completion], installed separately.

++++
<figure>
    <title>Gradle Completion</title>
    <imageobject>
        <imagedata fileref="img/gradle-completion-4.0.gif"/>
    </imageobject>
</figure>
++++

[[sec:command_line_debugging]]
=== Debugging options

`-?`, `-h`, `--help`::
Shows a help message with all available CLI options.

`-v`, `--version`::
Prints Gradle, Groovy, Ant, JVM, and operating system version information.

`-S`, `--full-stacktrace`::
Print out the full (very verbose) stacktrace for any exceptions. See also <<sec:command_line_logging, logging options>>.

`-s`, `--stacktrace`::
Print out the stacktrace also for user exceptions (e.g. compile error).  See also <<sec:command_line_logging, logging options>>.

`--scan`::
Create a https://gradle.com/build-scans[build scan] with fine-grained information about all aspects of your Gradle build.

`-Dorg.gradle.debug=true`::
Debug Gradle client (non-Daemon) process. Gradle will wait for you to attach a debugger at `localhost:5005` by default.

`-Dorg.gradle.daemon.debug=true`::
Debug <<gradle_daemon, Gradle Daemon>> process.

[[sec:command_line_performance]]
=== Performance options
Try these options when optimizing build performance. Learn more about https://guides.gradle.org/performance/[improving performance of Gradle builds here].

Many of these options can be specified in `gradle.properties` so command-line flags are not necessary. See the <<sec:gradle_configuration_properties, configuring build environment guide>>.

`--build-cache`, `--no-build-cache`::
Toggles the <<build_cache, Gradle build cache>>. Gradle will try to reuse outputs from previous builds. _Default is off_.

`--configure-on-demand`, `--no-configure-on-demand`::
Toggles <<configuration_on_demand, Configure-on-demand>>. Only relevant projects are configured in this build run. _Default is off_.

`--max-workers`::
Sets maximum number of workers that Gradle may use. _Default is number of processors_.

`--parallel`, `--no-parallel`::
Build projects in parallel. For limitations of this option please see <<sec:parallel_execution>>. _Default is off_.

`--profile`::
Generates a high-level performance report in the `$buildDir/reports/profile` directory. `--scan` is preferred.

`--scan`::
Generate a build scan with detailed performance diagnostics.

image:img/gradle-core-test-build-scan-performance.png[Build Scan performance report]

==== Gradle daemon options
You can manage the <<gradle_daemon,Gradle Daemon>> through the following command line options.

`--daemon`, `--no-daemon`::
Use the <<gradle_daemon, Gradle Daemon>> to run the build. Starts the daemon if not running or existing daemon busy. _Default is on_.

`--foreground`::
Starts the Gradle Daemon in a foreground process.

`--status` (Standalone command)::
Run `gradle --status` to list running and recently stopped Gradle daemons. Only displays daemons of the same Gradle version.

`--stop` (Standalone command)::
Run `gradle --stop` to stop all Gradle Daemons of the same version.

`-Dorg.gradle.daemon.idletimeout=(number of milliseconds)`::
Gradle Daemon will stop itself after this number of milliseconds of idle time. _Default is 10800000_ (3 hours).

[[sec:command_line_logging]]
=== Logging options

==== Setting log level
You can customize the verbosity of Gradle logging with the following options, ordered from least verbose to most verbose. Learn more in the <<logging, logging documentation>>.

`-Dorg.gradle.logging.level=(quiet,warn,lifecycle,info,debug)`::
Set logging level via Gradle properties.

`-q`, `--quiet`::
Log errors only.

`-w`, `--warn`::
Set log level to warn.

`-i`, `--info`::
Set log level to info.

`-d`, `--debug`::
Log in debug mode (includes normal stacktrace).

Lifecycle is the default log level.

==== Customizing log format
You can control the use of rich output (colors and font variants) by specifying the "console" mode in the following ways:

`-Dorg.gradle.console=(auto,plain,rich,verbose)`::
Specify console mode via Gradle properties. Different modes described immediately below.

`--console=(auto,plain,rich,verbose)`::
Specifies which type of console output to generate.
+
Set to `plain` to generate plain text only. This option disables all color and other rich output in the console output. This is the default when Gradle is _not_ attached to a terminal.
+
Set to `auto` (the default) to enable color and other rich output in the console output when the build process is attached to a console, or to generate plain text only when not attached to a console. _This is the default when Gradle is attached to a terminal._
+
Set to `rich` to enable color and other rich output in the console output, regardless of whether the build process is not attached to a console. When not attached to a console, the build output will use ANSI control characters to generate the rich output.
+
Set to `verbose` to enable color and other rich output like the `rich`, but output task names and outcomes at the lifecycle log level, as is done by default in Gradle 3.5 and earlier.

==== Showing or hiding warnings
By default, Gradle won't display all warnings (e.g. deprecation warnings). Instead, Gradle will collect them and render a summary at the end of the build like:

----
There're <number> deprecation warnings, which may break the build in Gradle 5.0. Please run with --warning-mode=all to see them.
----

You can control the verbosity of warnings on the console with the following options:

`-Dorg.gradle.warning.mode=(all,none,summary)`::
Specify warning mode via <<sec:gradle_properties, Gradle properties>>. Different modes described immediately below.

`--warning-mode=(all,none,summary)`::
Specifies how to log warnings. Default is `summary`.
+
Set to `all` to log all warnings.
+
Set to `summary` to suppress all warnings and log a summary at the end of the build.
+
Set to `none` to suppress all warnings, including the summary at the end of the build.

==== Rich Console
Gradle's rich console displays extra information while builds are running.

image::img/rich-cli.png[alt="Gradle Rich Console"]

Features:

 * Logs above grouped by task that generated them
 * Progress bar and timer visually describe overall status
 * Parallel work-in-progress lines below describe what is happening now

[[sec:command_line_execution_options]]
=== Execution options
The following options affect how builds are executed, by changing what is built or how dependencies are resolved.

`--include-build`::
Run the build as a composite, including the specified build. See <<composite_builds, Composite Builds>>.

`--offline`::
Specifies that the build should operate without accessing network resources. Learn more about <<cache_command_line_options,options to override dependency caching>>.

`--refresh-dependencies`::
Refresh the state of dependencies. Learn more about how to use this in the dependency management docs.<<cache_command_line_options, dependency management docs>>.

`--dry-run`::
Run Gradle with all task actions disabled. Use this to show which task would have executed.

[[sec:command_line_bootstrapping_projects]]
=== Bootstrapping new projects

==== Creating new Gradle builds
Use the built-in `gradle init` task to create a new Gradle builds, with new or existing projects.

----
❯ gradle init
----

Most of the time you'll want to specify a project type. Available types include `basic` (default), `java-library`, `java-application`, and more. See <<build_init_plugin, init plugin documentation>> for details.

----
❯ gradle init --type java-library
----

==== Standardize and provision Gradle
The built-in `gradle wrapper` task generates a script, `gradlew`, that invokes a declared version of Gradle, downloading it beforehand if necessary.

----
❯ gradle wrapper --gradle-version=4.4
----

You can also specify `--distribution-type=(bin|all)`, `--gradle-distribution-url`, `--gradle-distribution-sha256-sum` in addition to `--gradle-version`. Full details on how to use these options are documented in the <<gradle_wrapper,Gradle wrapper section>>.

=== Environment options
You can customize many aspects about where build scripts, settings, caches, and so on through the options below. Learn more about customizing your <<build_environment, build environment>>.

`-b`, `--build-file`::
Specifies the build file. For example: `gradle --build-file=foo.gradle`. The default is `build.gradle`, then `build.gradle.kts`, then `myProjectName.gradle`.

`-c`, `--settings-file`::
Specifies the settings file. For example: `gradle --settings-file=somewhere/else/settings.gradle`

`-g`, `--gradle-user-home`::
Specifies the Gradle user home directory. The default is the `.gradle` directory in the user's home directory.

`-p`, `--project-dir`::
Specifies the start directory for Gradle. Defaults to current directory.

`--project-cache-dir`::
Specifies the project-specific cache directory. Default value is `.gradle` in the root project directory.

`-u`, `--no-search-upward` (deprecated)::
Don't search in parent directories for a `settings.gradle` file.

`-D`, `--system-prop`::
Sets a system property of the JVM, for example `-Dmyprop=myvalue`. See <<sec:gradle_system_properties>>.

`-I`, `--init-script`::
Specifies an initialization script. See <<init_scripts>>.

`-P`, `--project-prop`::
Sets a project property of the root project, for example `-Pmyprop=myvalue`. See <<sec:project_properties>>.

`-Dorg.gradle.jvmargs`::
Set JVM arguments.

`-Dorg.gradle.java.home`::
Set JDK home dir.

[[sec:command_line_project_reporting]]
=== Project reporting

Gradle provides several built-in tasks which show particular details of your build. This can be useful for understanding the structure and dependencies of your build, and for debugging problems.

You can get basic help about available reporting options using `gradle help`.

==== Listing projects

Running `gradle projects` gives you a list of the sub-projects of the selected project, displayed in a hierarchy.

----
❯ gradle projects
----

You also get a project report within build scans. Learn more about https://guides.gradle.org/creating-build-scans/[creating build scans].

==== Listing tasks

Running `gradle tasks` gives you a list of the main tasks of the selected project. This report shows the default tasks for the project, if any, and a description for each task.

----
❯ gradle tasks
----

By default, this report shows only those tasks which have been assigned to a task group. You can obtain more information in the task listing using the `--all` option.

----
❯ gradle tasks --all
----

[[sec:show_task_details]]
==== Show task usage details

Running `gradle help --task someTask` gives you detailed information about a specific task.

++++
<sample id="taskHelp" dir="userguide/tutorial/projectReports" title="Obtaining detailed help for tasks">
    <output args="-q help --task libs"/>
</sample>
++++

This information includes the full task path, the task type, possible command line options and the description of the given task.

==== Reporting dependencies

Build scans give a full, visual report of what project and binary dependencies exist on which configurations, transitive dependencies, and dependency version selection.

----
❯ gradle myTask --scan
----

This will give you a link to a web-based report, where you can find dependency information like this.

image::img/gradle-core-test-build-scan-dependencies.png[Build Scan dependencies report]

==== Listing project dependencies

Running `gradle dependencies` gives you a list of the dependencies of the selected project, broken down by configuration. For each configuration, the direct and transitive dependencies of that configuration are shown in a tree. Below is an example of this report:

----
❯ gradle dependencies
----

Running `gradle buildEnvironment` visualises the buildscript dependencies of the selected project, similarly to how `gradle dependencies` visualizes the dependencies of the software being built.

----
❯ gradle buildEnvironment
----

Running `gradle dependencyInsight` gives you an insight into a particular dependency (or dependencies) that match specified input.

----
❯ gradle dependencyInsight
----

Since a dependency report can get large, it can be useful to restrict the report to a particular configuration. This is achieved with the optional `--configuration` parameter:

++++
<sample id="dependencyListReportFiltered" dir="userguide/tutorial/projectReports" title="Filtering dependency report by configuration">
    <output args="-q api:dependencies --configuration testCompile"/>
</sample>
++++

[[sec:listing_properties]]
==== Listing project properties

Running `gradle properties` gives you a list of the properties of the selected project.

++++
<sample id="propertyListReport" dir="userguide/tutorial/projectReports" title="Information about properties">
    <output args="-q api:properties" ignoreExtraLines="true"/>
</sample>
++++

==== Software Model reports

You can get a hierarchical view of elements for <<software_model,software model>> projects (deprecated) using the `model` task:

----
❯ gradle model
----

Learn more about <<model-report,the model report>> in the software model documentation.

// Copyright 2017 the original author or authors.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//      http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

[[command_line_interface]]
== Command-Line Interface

[.lead]
The command-line interface is one of the primary methods of interacting with Gradle. The following serves as a reference of executing and customizing Gradle use of a command-line or when writing scripts or configuring continuous integration.

Use of the <<gradle_wrapper, Gradle Wrapper>> is highly encouraged. You should substitute `./gradlew` or `gradlew.bat` for `gradle` in all following examples when using the Wrapper.

Executing Gradle on the command-line conforms to the following structure. Options are allowed before and after task names.
----
gradle [taskName...] [--option-name...]
----

If multiple tasks are specified, they should be separated with a space.

Options that accept values can be specified with or without `=` between the option and argument; however, use of `=` is recommended.
----
--console=plain
----

Options that enable behavior have long-form options with inverses specified with `--no-`. The following are opposites.
----
--build-cache
--no-build-cache
----

Many long-form options, have short option equivalents. The following are equivalent:
----
--help
-h
----

[NOTE]
====
Many command-line flags can be specified in `gradle.properties` to avoid needing to be typed. See the <<sec:gradle_configuration_properties, configuring build environment guide>> for details.
====

The following sections describe use of the Gradle command-line interface, grouped roughly by user goal. Some plugins also add their own command line options, for example <<test_filtering,`--tests` for Java test filtering>>.

[[sec:command_line_executing_tasks]]
=== Executing tasks

You can run a task and all of its dependencies.
----
❯ gradle myTask
----

You can learn about what projects and tasks are available in the <<sec:command_line_project_reporting, project reporting section>>.

==== Executing tasks in multi-project builds
In a <<intro_multi_project_builds, multi-project build>>, subproject tasks can be executed with ":" separating subproject name and task name. The following are equivalent _when run from the root project_.

----
❯ gradle :mySubproject:taskName
❯ gradle mySubproject:taskName
----

You can also run a task for all subprojects using the task name only. For example, this will run the "test" task for all subprojects when invoked from the root project directory.

----
❯ gradle test
----

When invoking Gradle from within a subproject, the project name should be omitted:

----
❯ cd mySubproject
❯ gradle taskName
----

[NOTE]
====
When executing the Gradle Wrapper from subprojects, one must reference `gradlew` relatively. For example: `../gradlew taskName`. The community http://www.gdub.rocks/[gdub project] aims to make this more convenient.
====

==== Executing multiple tasks
You can also specify multiple tasks. For example, the following will execute the `compile` and `test` tasks in the order that they are listed on the command-line and will also execute the dependencies for each task.

----
❯ gradle compile test
----

[[sec:excluding_tasks_from_the_command_line]]
==== Excluding tasks from execution
You can exclude a task from being executed using the `-x` or `--exclude-task` command-line option and providing the name of the task to exclude.

++++
<figure>
    <title>Example Task Graph</title>
    <imageobject>
        <imagedata fileref="img/commandLineTutorialTasks.png"/>
    </imageobject>
</figure>
++++

++++
<sample id="excludeTask" dir="userguide/tutorial/excludeTasks" title="Excluding tasks">
    <output args="dist --exclude-task test"/>
</sample>
++++

You can see that the `test` task is not executed, even though it is a dependency of the `dist` task. The `test` task's dependencies such as `compileTest` are not executed either. Those dependencies of `test` that are required by another task, such as `compile`, are still executed.

[[sec:rerun_tasks]]
==== Forcing tasks to execute

You can force Gradle to execute all tasks ignoring <<sec:up_to_date_checks,up-to-date checks>> using the `--rerun-tasks` option:

----
❯ gradle test --rerun-tasks
----

This will force `test` and _all_ task dependencies of `test` to execute. It's a little like running `gradle clean test`, but without the build's generated output being deleted.

[[sec:continue_build_on_failure]]
==== Continuing the build when a failure occurs

By default, Gradle will abort execution and fail the build as soon as any task fails. This allows the build to complete sooner, but hides other failures that would have occurred. In order to discover as many failures as possible in a single build execution, you can use the `--continue` option.

----
❯ gradle test --continue
----

When executed with `--continue`, Gradle will execute _every_ task to be executed where all of the dependencies for that task completed without failure, instead of stopping as soon as the first failure is encountered. Each of the encountered failures will be reported at the end of the build.

If a task fails, any subsequent tasks that were depending on it will not be executed. For example, tests will not run if there is a compilation failure in the code under test; because the test task will depend on the compilation task (either directly or indirectly).

[[sec:command_line_completion]]
=== Command-Line completion

Gradle provides bash and zsh tab completion support for tasks, options, and Gradle properties through https://github.com/gradle/gradle-completion[gradle-completion], installed separately.

++++
<figure>
    <title>Gradle Completion</title>
    <imageobject>
        <imagedata fileref="img/gradle-completion-4.0.gif"/>
    </imageobject>
</figure>
++++

[[sec:command_line_debugging]]
=== Debugging options

`-?`, `-h`, `--help`::
Shows a help message with all available CLI options.

`-v`, `--version`::
Prints Gradle, Groovy, Ant, JVM, and operating system version information.

`-S`, `--full-stacktrace`::
Print out the full (very verbose) stacktrace for any exceptions. See also <<sec:command_line_logging, logging options>>.

`-s`, `--stacktrace`::
Print out the stacktrace also for user exceptions (e.g. compile error).  See also <<sec:command_line_logging, logging options>>.

`--scan`::
Create a https://gradle.com/build-scans[build scan] with fine-grained information about all aspects of your Gradle build.

`-Dorg.gradle.debug=true`::
Debug Gradle client (non-Daemon) process. Gradle will wait for you to attach a debugger at `localhost:5005` by default.

`-Dorg.gradle.daemon.debug=true`::
Debug <<gradle_daemon, Gradle Daemon>> process.

[[sec:command_line_performance]]
=== Performance options
Try these options when optimizing build performance. Learn more about https://guides.gradle.org/performance/[improving performance of Gradle builds here].

Many of these options can be specified in `gradle.properties` so command-line flags are not necessary. See the <<sec:gradle_configuration_properties, configuring build environment guide>>.

`--build-cache`, `--no-build-cache`::
Toggles the <<build_cache, Gradle build cache>>. Gradle will try to reuse outputs from previous builds. _Default is off_.

`--configure-on-demand`, `--no-configure-on-demand`::
Toggles <<configuration_on_demand, Configure-on-demand>>. Only relevant projects are configured in this build run. _Default is off_.

`--max-workers`::
Sets maximum number of workers that Gradle may use. _Default is number of processors_.

`--parallel`, `--no-parallel`::
Build projects in parallel. For limitations of this option please see <<sec:parallel_execution>>. _Default is off_.

`--profile`::
Generates a high-level performance report in the `$buildDir/reports/profile` directory. `--scan` is preferred.

`--scan`::
Generate a build scan with detailed performance diagnostics.

image:img/gradle-core-test-build-scan-performance.png[Build Scan performance report]

==== Gradle daemon options
You can manage the <<gradle_daemon,Gradle Daemon>> through the following command line options.

`--daemon`, `--no-daemon`::
Use the <<gradle_daemon, Gradle Daemon>> to run the build. Starts the daemon if not running or existing daemon busy. _Default is on_.

`--foreground`::
Starts the Gradle Daemon in a foreground process.

`--status` (Standalone command)::
Run `gradle --status` to list running and recently stopped Gradle daemons. Only displays daemons of the same Gradle version.

`--stop` (Standalone command)::
Run `gradle --stop` to stop all Gradle Daemons of the same version.

`-Dorg.gradle.daemon.idletimeout=(number of milliseconds)`::
Gradle Daemon will stop itself after this number of milliseconds of idle time. _Default is 10800000_ (3 hours).

[[sec:command_line_logging]]
=== Logging options

==== Setting log level
You can customize the verbosity of Gradle logging with the following options, ordered from least verbose to most verbose. Learn more in the <<logging, logging documentation>>.

`-Dorg.gradle.logging.level=(quiet,warn,lifecycle,info,debug)`::
Set logging level via Gradle properties.

`-q`, `--quiet`::
Log errors only.

`-w`, `--warn`::
Set log level to warn.

`-i`, `--info`::
Set log level to info.

`-d`, `--debug`::
Log in debug mode (includes normal stacktrace).

Lifecycle is the default log level.

==== Customizing log format
You can control the use of rich output (colors and font variants) by specifying the "console" mode in the following ways:

`-Dorg.gradle.console=(auto,plain,rich,verbose)`::
Specify console mode via Gradle properties. Different modes described immediately below.

`--console=(auto,plain,rich,verbose)`::
Specifies which type of console output to generate.
+
Set to `plain` to generate plain text only. This option disables all color and other rich output in the console output. This is the default when Gradle is _not_ attached to a terminal.
+
Set to `auto` (the default) to enable color and other rich output in the console output when the build process is attached to a console, or to generate plain text only when not attached to a console. _This is the default when Gradle is attached to a terminal._
+
Set to `rich` to enable color and other rich output in the console output, regardless of whether the build process is not attached to a console. When not attached to a console, the build output will use ANSI control characters to generate the rich output.
+
Set to `verbose` to enable color and other rich output like the `rich`, but output task names and outcomes at the lifecycle log level, as is done by default in Gradle 3.5 and earlier.

==== Showing or hiding warnings
By default, Gradle won't display all warnings (e.g. deprecation warnings). Instead, Gradle will collect them and render a summary at the end of the build like:

----
There're <number> deprecation warnings, which may break the build in Gradle 5.0. Please run with --warning-mode=all to see them.
----

You can control the verbosity of warnings on the console with the following options:

`-Dorg.gradle.warning.mode=(all,none,summary)`::
Specify warning mode via <<sec:gradle_properties, Gradle properties>>. Different modes described immediately below.

`--warning-mode=(all,none,summary)`::
Specifies how to log warnings. Default is `summary`.
+
Set to `all` to log all warnings.
+
Set to `summary` to suppress all warnings and log a summary at the end of the build.
+
Set to `none` to suppress all warnings, including the summary at the end of the build.

==== Rich Console
Gradle's rich console displays extra information while builds are running.

image::img/rich-cli.png[alt="Gradle Rich Console"]

Features:

 * Logs above grouped by task that generated them
 * Progress bar and timer visually describe overall status
 * Parallel work-in-progress lines below describe what is happening now

[[sec:command_line_execution_options]]
=== Execution options
The following options affect how builds are executed, by changing what is built or how dependencies are resolved.

`--include-build`::
Run the build as a composite, including the specified build. See <<composite_builds, Composite Builds>>.

`--offline`::
Specifies that the build should operate without accessing network resources. Learn more about <<cache_command_line_options,options to override dependency caching>>.

`--refresh-dependencies`::
Refresh the state of dependencies. Learn more about how to use this in the dependency management docs.<<cache_command_line_options, dependency management docs>>.

`--dry-run`::
Run Gradle with all task actions disabled. Use this to show which task would have executed.

[[sec:command_line_bootstrapping_projects]]
=== Bootstrapping new projects

==== Creating new Gradle builds
Use the built-in `gradle init` task to create a new Gradle builds, with new or existing projects.

----
❯ gradle init
----

Most of the time you'll want to specify a project type. Available types include `basic` (default), `java-library`, `java-application`, and more. See <<build_init_plugin, init plugin documentation>> for details.

----
❯ gradle init --type java-library
----

==== Standardize and provision Gradle
The built-in `gradle wrapper` task generates a script, `gradlew`, that invokes a declared version of Gradle, downloading it beforehand if necessary.

----
❯ gradle wrapper --gradle-version=4.4
----

You can also specify `--distribution-type=(bin|all)`, `--gradle-distribution-url`, `--gradle-distribution-sha256-sum` in addition to `--gradle-version`. Full details on how to use these options are documented in the <<gradle_wrapper,Gradle wrapper section>>.

=== Environment options
You can customize many aspects about where build scripts, settings, caches, and so on through the options below. Learn more about customizing your <<build_environment, build environment>>.

`-b`, `--build-file`::
Specifies the build file. For example: `gradle --build-file=foo.gradle`. The default is `build.gradle`, then `build.gradle.kts`, then `myProjectName.gradle`.

`-c`, `--settings-file`::
Specifies the settings file. For example: `gradle --settings-file=somewhere/else/settings.gradle`

`-g`, `--gradle-user-home`::
Specifies the Gradle user home directory. The default is the `.gradle` directory in the user's home directory.

`-p`, `--project-dir`::
Specifies the start directory for Gradle. Defaults to current directory.

`--project-cache-dir`::
Specifies the project-specific cache directory. Default value is `.gradle` in the root project directory.

`-u`, `--no-search-upward` (deprecated)::
Don't search in parent directories for a `settings.gradle` file.

`-D`, `--system-prop`::
Sets a system property of the JVM, for example `-Dmyprop=myvalue`. See <<sec:gradle_system_properties>>.

`-I`, `--init-script`::
Specifies an initialization script. See <<init_scripts>>.

`-P`, `--project-prop`::
Sets a project property of the root project, for example `-Pmyprop=myvalue`. See <<sec:project_properties>>.

`-Dorg.gradle.jvmargs`::
Set JVM arguments.

`-Dorg.gradle.java.home`::
Set JDK home dir.

[[sec:command_line_project_reporting]]
=== Project reporting

Gradle provides several built-in tasks which show particular details of your build. This can be useful for understanding the structure and dependencies of your build, and for debugging problems.

You can get basic help about available reporting options using `gradle help`.

==== Listing projects

Running `gradle projects` gives you a list of the sub-projects of the selected project, displayed in a hierarchy.

----
❯ gradle projects
----

You also get a project report within build scans. Learn more about https://guides.gradle.org/creating-build-scans/[creating build scans].

==== Listing tasks

Running `gradle tasks` gives you a list of the main tasks of the selected project. This report shows the default tasks for the project, if any, and a description for each task.

----
❯ gradle tasks
----

By default, this report shows only those tasks which have been assigned to a task group. You can obtain more information in the task listing using the `--all` option.

----
❯ gradle tasks --all
----

[[sec:show_task_details]]
==== Show task usage details

Running `gradle help --task someTask` gives you detailed information about a specific task.

++++
<sample id="taskHelp" dir="userguide/tutorial/projectReports" title="Obtaining detailed help for tasks">
    <output args="-q help --task libs"/>
</sample>
++++

This information includes the full task path, the task type, possible command line options and the description of the given task.

==== Reporting dependencies

Build scans give a full, visual report of what project and binary dependencies exist on which configurations, transitive dependencies, and dependency version selection.

----
❯ gradle myTask --scan
----

This will give you a link to a web-based report, where you can find dependency information like this.

image::img/gradle-core-test-build-scan-dependencies.png[Build Scan dependencies report]

==== Listing project dependencies

Running `gradle dependencies` gives you a list of the dependencies of the selected project, broken down by configuration. For each configuration, the direct and transitive dependencies of that configuration are shown in a tree. Below is an example of this report:

----
❯ gradle dependencies
----

Running `gradle buildEnvironment` visualises the buildscript dependencies of the selected project, similarly to how `gradle dependencies` visualizes the dependencies of the software being built.

----
❯ gradle buildEnvironment
----

Running `gradle dependencyInsight` gives you an insight into a particular dependency (or dependencies) that match specified input.

----
❯ gradle dependencyInsight
----

Since a dependency report can get large, it can be useful to restrict the report to a particular configuration. This is achieved with the optional `--configuration` parameter:

++++
<sample id="dependencyListReportFiltered" dir="userguide/tutorial/projectReports" title="Filtering dependency report by configuration">
    <output args="-q api:dependencies --configuration testCompile"/>
</sample>
++++

[[sec:listing_properties]]
==== Listing project properties

Running `gradle properties` gives you a list of the properties of the selected project.

++++
<sample id="propertyListReport" dir="userguide/tutorial/projectReports" title="Information about properties">
    <output args="-q api:properties" ignoreExtraLines="true"/>
</sample>
++++

==== Software Model reports

You can get a hierarchical view of elements for <<software_model,software model>> projects (deprecated) using the `model` task:

----
❯ gradle model
----

Learn more about <<model-report,the model report>> in the software model documentation.

=== Common tasks

The following are task conventions applied by built-in and most major Gradle plugins.

==== Computing all outputs

It is common in Gradle builds for the `build` task to designate assembling all outputs and running all checks.

----
❯ gradle build
----

==== Running applications

It is common for applications to be run with the `run` task, which assembles the application and executes some script or binary.

----
❯ gradle run
----

==== Running all checks

It is common for _all_ verification tasks, including tests and linting, to be executed using the `check` task.

----
❯ gradle check
----

==== Cleaning outputs

You can delete the contents of the build directory using the `clean` task, though doing so will cause pre-computed outputs to be lost, causing significant additional build time for the subsequent task execution.

----
❯ gradle clean
----


BZ1759428 to align sample capacity to 5Gi

// Module included in the following assemblies:
//
// * storage/persistent-storage/persistent-storage-nfs.adoc

[id="persistent-storage-nfs-provisioning_{context}"]
= Provisioning

Storage must exist in the underlying infrastructure before it can be
mounted as a volume in {product-title}. To provision NFS volumes,
a list of NFS servers and export paths are all that is required.

.Procedure

. Create an object definition for the PV:
+
[source,yaml]
----
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001 <1>
spec:
  capacity:
    storage: 5Gi <2>
  accessModes:
  - ReadWriteOnce <3>
  nfs: <4>
    path: /tmp <5>
    server: 172.17.0.2 <6>
  persistentVolumeReclaimPolicy: Retain <7>
----
<1> The name of the volume. This is the PV identity in various `oc <command>
pod` commands.
<2> The amount of storage allocated to this volume.
<3> Though this appears to be related to controlling access to the volume,
it is actually used similarly to labels and used to match a PVC to a PV.
Currently, no access rules are enforced based on the `accessModes`.
<4> The volume type being used, in this case the `nfs` plug-in.
<5> The path that is exported by the NFS server.
<6> The host name or IP address of the NFS server.
<7> The reclaim policy for the PV. This defines what happens to a volume
when released.
+
[NOTE]
====
Each NFS volume must be mountable by all schedulable nodes in the cluster.
====

. Verify that the PV was created:
+
----
$ oc get pv
NAME     LABELS    CAPACITY     ACCESSMODES   STATUS      CLAIM  REASON    AGE
pv0001   <none>    5368709120   RWO           Available                    31s
----

. Create a persistent volume claim that binds to the new PV:
+
[source,yaml]
----
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-claim1
spec:
  accessModes:
    - ReadWriteOnce <1>
  resources:
    requests:
      storage: 5Gi <2>
----
<1> As mentioned above for PVs, the `*accessModes*` do not enforce security, but
rather act as labels to match a PV to a PVC.
<2> This claim looks for PVs offering *5Gi* or greater capacity.

. Verify that the persistent volume claim was created:
+
----
$ oc get pvc
NAME         STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
nfs-claim1   Bound    pv0001   5Gi        RWO            gp2            2m
----

// Module included in the following assemblies:
//
// * storage/persistent-storage/persistent-storage-nfs.adoc

[id="persistent-storage-nfs-provisioning_{context}"]
= Provisioning

Storage must exist in the underlying infrastructure before it can be
mounted as a volume in {product-title}. To provision NFS volumes,
a list of NFS servers and export paths are all that is required.

.Procedure

. Create an object definition for the PV:
+
[source,yaml]
----
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001 <1>
spec:
  capacity:
    storage: 5Gi <2>
  accessModes:
  - ReadWriteOnce <3>
  nfs: <4>
    path: /tmp <5>
    server: 172.17.0.2 <6>
  persistentVolumeReclaimPolicy: Retain <7>
----
<1> The name of the volume. This is the PV identity in various `oc <command>
pod` commands.
<2> The amount of storage allocated to this volume.
<3> Though this appears to be related to controlling access to the volume,
it is actually used similarly to labels and used to match a PVC to a PV.
Currently, no access rules are enforced based on the `accessModes`.
<4> The volume type being used, in this case the `nfs` plug-in.
<5> The path that is exported by the NFS server.
<6> The host name or IP address of the NFS server.
<7> The reclaim policy for the PV. This defines what happens to a volume
when released.
+
[NOTE]
====
Each NFS volume must be mountable by all schedulable nodes in the cluster.
====

. Verify that the PV was created:
+
----
$ oc get pv
NAME     LABELS    CAPACITY     ACCESSMODES   STATUS      CLAIM  REASON    AGE
pv0001   <none>    5368709120   RWO           Available                    31s
----

. Create a persistent volume claim which binds to the new PV:
+
[source,yaml]
----
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-claim1
spec:
  accessModes:
    - ReadWriteOnce <1>
  resources:
    requests:
      storage: 5Gi <2>
----
<1> As mentioned above for PVs, the `*accessModes*` do not enforce security, but
rather act as labels to match a PV to a PVC.
<2> This claim looks for PVs offering *1Gi* or greater capacity.

. Verify that the persistent volume claim was created:
+
----
$ oc get pvc
NAME         STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
nfs-claim1   Bound    pv0001   4Gi        RWO            gp2            2m
----


Update 2015-07-06-How-long-does-it-take-you-to-create-a-RevealJS-presentation.adoc

= How long does it take you to create a RevealJS presentation ?

:hp-tags: asciidoctor, revealjs, lazybones

After a couple of months, I finally found a topic to write the very first post in my new http://hubpress.io/[Hubpress.io] blog.

Today, we are going to talk about *Asciidoctor* and *RevealJS*. As you might know, you can use Asciidoctor to write and create RevealJS presentations. Therefore, if you are not familiar with Asciidoctor creating the first presentation can be tricky especially if you plan to use diagrams (or other external modules).

Recently thanks to Andres Almiray (https://twitter.com/aalmiray[@aalmiray]), I discovered https://github.com/pledbrook/lazybones[Lazybones]. A very simple template generator for Gradle projects. With Lazybones you can start a Gradle projects such as Spring boot, Groovy or even AsciidoctorJ using only 1 command. Therefore you still had to  customize the generated project to be able to generate a RevealJS slideshow.

That's why I have created the Asciidoctor-RevealJS template for Lazybones.

== Long story short

=== Let's play

Once you installed everything (http://gvmtool.net[GVM] and Lazybones) all you need to do is:

[source]
$ lazybones create asciidoctor-revealjs 1.0.0 myAwesomePresentation

Then answer the questions (title for your presentation, who you are and the revealjs theme to use) and you are good to go.
icon:thumbs-o-up[]

If you look your current directory you'll found something like:

[source]
----
gscheibel@~/labs/adocs/blog/myAwesomePresentation $ tree
├── README.md
├── build.gradle
└── src
    └── docs
        └── asciidoc
            ├── images
            ├── slides
            ├── slides.adoc
            ├── snippets
            └── styles
----

All you need is under `src/docs/asciidoc/`, by default the main slide is `slides.adoc`. Remember the questions asked during the presentation setup, those information (title and author) are reused here. The theme can be found in the `build.gradle` file.

[source]
----
= Asciidoctor is awesome
Guillaume Scheibel <guillaume.scheibel@gmail.com>

:imagesdir: images
:sourcedir: snippets
----

=== Let's write

A way to create your presentation is `one slide one file`, it means every time you want to create a slide, you create a file (in slides/ for instance) and then include it in slides.adoc using the include directive (eg: `include::slides/coolSlides.adoc[]`)

=== Let's create

To create your presentation, all you need is a simple

[source]
$ gradle asciidoctor

Then you'll find your presentation under `build/asciidoc/html5`.

Interested by hot-relaod while you're writing ? `gradle watch` is going to become your best friend.

== Finally

To answer the question in the title, it only takes few seconds to create an RevealJS presentation thanks to *Asciidoctor* and *Lazybones*.
The template sources are available on https://github.com/asciidoctor/asciidoctor-lazybones[Github] and the binaries on https://bintray.com/asciidoctor/maven/asciidoctor-revealjs-template/view[Bintray].

= How long does it take you to create a RevealJS presentation ?

:hp-tags: asciidoctor, revealjs, lazybones

After couple of months, I finally found a topic to write the very first post in my new http://hubpress.io/[Hubpress.io] blog.

Today, we are going to talk about *Asciidoctor* and *RevealJS*. As you might know, you can use Asciidoctor to write and create RevealJS presentations. Therefore, if you are not familiar with Asciidoctor creating the first presentation can be tricky especially if you plan to use diagrams (or other external modules).

Recently thanks to Andres Almiray (https://twitter.com/aalmiray[@aalmiray]), I discovered https://github.com/pledbrook/lazybones[Lazybones]. A very simple template generator for Gradle projects. With Lazybones you can start a Gradle projects such as Spring boot, Groovy or even AsciidoctorJ using only 1 command. Therefore you still had to  customize the generated project to be able to generate a RevealJS slideshow.

That's why I have created the Asciidoctor-RevealJS template for Lazybones.

== Long story short

=== Let's play

Once you installed everything (GVM and Lazybones) all you need to do is:

[source]
$ lazybones create asciidoctor-revealjs 1.0.0 myAwesomePresentation

Then answer the questions (title for your presentation, who you are and the revealjs theme) and you are good to go.
icon:thumbs-o-up[]

If you look your current directory you will found something like:

[source]
----
gscheibel@~/labs/adocs/blog/myAwesomePresentation $ tree
├── README.md
├── build.gradle
└── src
    └── docs
        └── asciidoc
            ├── images
            ├── slides
            ├── slides.adoc
            ├── snippets
            └── styles
----

All you need is under `src/docs/asciidoc/`, by default the main slide is `slides.adoc`. Remember the questions asked during the presentation setup, those information (title and author) are reused here. The theme can be found in the `build.gradle` file.

[source]
----
= Asciidoctor is awesome
Guillaume Scheibel <guillaume.scheibel@gmail.com>

:imagesdir: images
:sourcedir: snippets
----

=== Let's write

A way to create your presentation is `one slide one file`, it means every time you want to create a slide, you create a file (in slides/ for instance) and then include it in slides.adoc using the include directive (eg: `include::slides/coolSlides.adoc[]`)

=== Let's create

To create your presentation, all you need is a simple

[source]
$ gradle asciidoctor

Then you'll find your presentation under `build/asciidoc/html5`.

Interested by hot-relaod while you're writing ? `gradle watch` is going to become your best friend.

== Finally

To answer the question in the title, it only takes few seconds to create an RevealJS presentation thanks to *Asciidoctor* and *Lazybones*.
The template sources are available on https://github.com/asciidoctor/asciidoctor-lazybones[Github] and the binaries on https://bintray.com/asciidoctor/maven/asciidoctor-revealjs-template/view[Bintray].


Update 2015-12-22-Performance-of-Microservices-frameworks.adoc

= Performance of Microservices frameworks
:hp-tags: Tech, Microservices, REST, performance

This is the follow-up of my article about https://cdelmas.github.io/2015/11/01/A-comparison-of-Microservices-Frameworks.html[Microservices Frameworks].

[options="header"]
|===
| Framework | Package size (MB) | Startup time (ms) 4+| GET (over 5 min) 4+| POST (over 10 min)

| | | | *_total_* | *_failed_* | *_mean (ms)_* | *_throughput (req/s)_* | *_total_* | *_failed_* | *_mean (ms)_* | *_throughput (req/s)_*

| Dropwizard |15 | 1047  |  |  | | | | | |

| Restlet |4,2 | 110 |  |  | | | | | |

| Restlet / Jetty | 5,8| 110 |  |  | | | | | |

| Restlet / Simple |4,5 | 110 |  |  | | | | | |

| Sparkjava |4,1 | 290 |  |  | | | | | |

| Spring Boot / Tomcat | 14 |6905 |  |  |  | | | | |

| Spring Boot / Jetty | 13 | 6905 |  |  |  | | | | |

| Spring Boot / Undertow | 14 | 6905 |  |  |  | | | | |

| vertx |5,1 | 7250 |  |  | | | | | |

|===

GET / POST
mean

- 790 ms    apollo (async: 600ms)
- 270 ms    dropwizard
- 205 ms    restlet
-  ms restlet / Jetty
- ms restlet / Simple
- 290 ms    sparkjava
- 6905 ms    spring-boot
- 7250 ms    vertx

throughput

- 560 r/s    apollo
- 1047 r/s    dropwizard
- 110 r/s    restlet
- 290 r/s    sparkjava
- 6905 r/s    spring-boot
- 7250 r/s    vertx

Using Gatling to measure the performance

Methodology

Get on a /hello endpoint, with 200 users making 1000 requests each (total: 200000); a request is considered as failed if it exceeds 60s. The test is time boxed (limit: 5 minutes).
Post on a /hello endpoint, with 200 users making 1000 requests each (total: 200000); a request is considered as failed if it exceeds 60s. The test is time boxed (limit: 10 minutes).

Response is json-encoded POJO
Payload is json.

Results

mean, throughput, errors


Update 2016-07-12-Un-vistazo-a-los-estilos-de-aprendizaje.adoc

= Un vistazo a los estilos de aprendizaje
:hp-tags: e-learning, innovación, estilos de aprendizaje,TIC, educación
:published_at: 2016-07-12

Dentro de las diversas acciones que un docente desarrolla en clase siempre debe tomar en cuenta los divesos estilos de aprendizaje de sus estudiantes, de esta manera podemos asegurar que cada actividad podrá generar un mejor aprendizaje en cada uno de ellos y responder a la diversidad de caracterísiticas de los mismo.

== Estilos de aprendizaje

El emplear metodologías que apunten a mantener como eje central al estudiante deberán tomar en cuenta la heterogeneidad del grupo y trabajar (planificando y aplicado) diversas estrategias didáctiva que permitan justamente que todo el grupo genere un aprendizaje significativo. Para esto imprescindible el proponer actividades direccionadas a sus estilos de aprendizaje, por ello, se revisará algunas de ellas con sus características.

image:https://s20.postimg.org/bt67sp50t/estilos4.png[Estilos de aprendizaje,]

Refiriéndose al tema Laura Frade, articula ocho capacidades que deben tener los docentes, estas capacidades interactúan entre sí para dar como resultado la óptima formación de los estudiantes:

1. Capacidad diagnóstica: capacidad de detectar las necesidades de aprendizaje del estudiante, alienearla a un estilo de aprendizaje y vincularla con una estrategia de aprendizaje.

2. Capacidad cognitiva: capacidad que guarda relación con la adquisición del conocimiento necesario para impartir los contenidos temáticos.

3. Capacidad ética: capacidad que incide en la toma de decisiones del docente sobre su compromiso ante la sociedad, la responsabilidad de trabajo, los valores que promoverá, los juicios de  valor que emitirá, la priorización del desarrollo de los estudiantes, la preocupación sobre su futuro laboral.

4. Capacidad lógica: capacidad para organizar el contenido temáticos de forma lógica-secuencial. Se demuestra por su, orden, graduación y dosificación.

5. Capacidad empática: capacidad que permite entender a los estudiantes en tres diferentes planos: afectivo, cognitivo y psicomotriz.

6. Capacidad comunicativa: habilidad para lograr la mediación entre el aprendizaje y la enseñanza.Se evidencia en el uso de los diferentes tipos de lenguaje que posibiliten al estudiante apropiarse del conocimiento y hacer su propia construcción significativa, lo que les permitirá aprender para la vida.

7. Capacidad lúdica: capacidad que permite diseñar y aplicar diversas estrategias de enseñanza-aprendizaje.

8. Capacidad metacognitiva: capacidad para evaluar el proceso enseñanza-aprendizaje en dos vías: hacia los alumnos verificando avances y estableciendo medidas correctivas, pero además hacia su propio desempeño como docente, lo que le permitirá mejorar día a día en su profesión.

Si nosotros como docentes contamos con estas habilidades, aseguraremos un buen trabajo con nuestros estudiantes.

=== ¿Qué son?

Se definen como las distintas maneras en que un individuo puede aprender; para Alonso y Gallego (1994) los estilos de aprendizaje son los rasgos cognitivos, afectivos y fisiológicos que sirven como indicadores relativamente estables de cómo los alumnos perciben interacciones y responden a sus ambientes de aprendizaje.

Se cree que todas las personas emplean un método particular de interacción, aceptación y procesado de estímulos e información. Las características sobre estilo de aprendizaje suelen formar parte de cualquier informe psicopedagógico que se elabore sobre un estudiante, y debiera ser el fundamento de las estrategias didácticas y refuerzos pedagógicos para que estos sean los más adecuados para el alumno.

Los diversos investigadores que han propuesto algún estilo de aprendizaje en cierto difieren de los componentes de los estilos de aprendizaje; sin embargo estos serían algunos de los más empleados:

* Condiciones ambientales
* Bagaje cultural
* Edad
* Preferencias de agrupamiento (se refiere a si se trabaja mejor individual-
mente o en equipo)
* Estilo seguido para la resolución de problemas
* Tipo de motivación, locus de control interno o externo

El analizar los diferentes estilos de aprendizjae que tienen nuestros estudiantes sin lugar a dudas permitirá que podamos tomar decisiones dirigidas a satisfacer cada necesidad singular en el grupo y con ellos que el conjunto de estudiantes logre la asimilización de conocimientos planificiada o quizás una superior.

=== Clasificación

Los modelos existentes sobre estilos de aprendizaje ofrecen un marco conceptual para entender los comportamientos observados en el aula, los cuales brindan una
explicación sobre la relación de esos comportamientos con la forma en que están aprendiendo los alumnos y el tipo de estrategias de enseñanza que pueden resultar más eficaces en un momento determinado, ya sea por el contendido temático en sí, o bien por las diversas interacciones sociales que se desarrollan en el aula.

De esta manera tenemos varias clasificaciones las cuales se muestran en la siguiente tabla:

image:https://s20.postimg.org/6t8rkqze5/estilos1.png[Calsificación estilos de apredizaje, 800,400 role=right]

=== Modelo de Kolb

El aprendizaje experiencial progresa a través de un ciclo de actividades a las que se conoce habitualmente como ciclo de aprendizaje de Kolb (David Kolb, 1984).

El ciclo tiene cuatro componentes, cada uno de los cuales plantea retos concretos a la hora de planificar actividades académicas.

image:http://image.slidesharecdn.com/estilos-de-aprendizaje-k-o-l-b2165/95/estilos-de-aprendizaje-k-o-l-b-5-728.jpg [ciclos modelo kolb]

Acorde este modelo una persona sulee establecer su estilo de aprendizaje en 1 o máximo 2 de estas fases y de esta menera podemos clasificar a nuestros estudiantes acorde la fase que prefieran trabajar.

* Activo
* Reflexivo
* Teórico
* Pragmático

=== Caráterísticas de cada estilo

Para lograr proponer/emplear estrategias de aprendizaje apropiadas para cada estilo revisemos las características de cada uno:

[cols="1,2,1,1", options="header,footer,autowidth"]
.Características Estilos de parendizaje modelo Kolb
|===
Estilo |Característica General |Cuando facilita el aprendizaje  |Cuando NO facilita el aprendizaje.
|Activos

|Se involucran totalmente y sin prejuicios en las experiencias nuevas.
Disfrutan el momento y cada acontecimiiento. Entusiastas ente lo nuevo. Actuan primero y luego piensan en las consecuencias. Disfrutan trabajando en equipo siendo el eje del grupo. Les aburre planificar a largo plazo y consolidar poryectos.
*La pregunta que buscan responder en el aprendizaje es: _¿Cómo?_*

|Plantendo actividades desafiantes . Actividades de resultados immediatos o a corto plazo. Actividades activas de emoción, drama, acción.

|Siendo pasivos. Demasiado análisis de un tema o mucha reflexión sobre algo. Trabajo individual.

|Reflexivo

|Adoptan una postura observadora de análsis en base a datos, experiencias desde varias perpectivas.Establecen conclusiones en base a argumentos sólidos y convincentes. Son precavidos y analizan todas las implicaciones de cualquier acción antes de ponerse en
movimiento. En las reuniones observan y escuchan antes de hablar procurando pasar desapercibidos. *La pregunta que quieren responder con el aprendizaje es: _¿Por qué?_*

|Cuando pueden tener una postura de observador. Analizar situaciones. Se les facilita información o datos. Tienen tiempo para reflexionar antes de actuar.

|Se exigen ser centro o eje de atención. Actividades de solución inmediata. Improvisación sobre algo. Actividades que le apresuren.

|Teóricos

|Adaptan e intergran las teorías o fundamentos de forma lógica. Organizan las cosas de forma secuencial, integrada y coherente. Analizan y sintetizan información de forma racional. No son subjetivos ni ilógicos. *La pregutna que quieren responder es: _¿Qué?_*

|Cuando se parte de teorías, modelos, sistemas. Ideas o conceptos desafiantes. Actividades que propicien la indagación o cuestionamientos.

|Actividades abiguas o que generen incertidumbre. Actividades/situaciones que prioricen sentimientos o emociones. Cuando no se les facilita la teoría o bases conceptuales.

|Prágmáticos

|Gustan de poner en práctica las ideas, teorías, técnicas nuevas y verificar su funcionamiento, forma de uso/aplicación. Generan/buscan ideas y las ejecutan inmediatamente. Se basan en la realidad para plantear alternativas a fin de de tomar decisiones sobre algo. Buscan desafíos, replantear algo con una diferente perspectiva. Discuten un tema brevemenete, les aburren los debates largos. *La pregunta que quieren responder es: _¿Qué pasaría si?_*

|Actividades que enlacen la teoría con la práctica. Visualizan trabajo/movimiento/acción. Posibilidad de aplicación de algo aprendido.

|Cuando todo queda en teoría. Lo aprendido no se vincula con la realidad o necesidades puntuales. Actividades que no se identifique una finalidad con claridad.

|===

NOTE: Bibliografía

* Maria Victoria González Clavero (2011). Estilos de aprendizaje y su influencia para aprender a aprender. Universidad Central “Marta Abreu” de Las Villas. Santa - Cuba. mariag@uclv.edu.cu http://goo.gl/fuDZPb

* Secretaría de Educación Pública - México (2005). Manual de estilos de aprendizaje, Material autoinstitucional para docentes y orientadores educativos. http://goo.gl/ZAeldY

* John Stephenson, Albert Sangrà (2009). Fundamentos del diseño técnico-pedagógico en e-learning. https://goo.gl/BGAm5A

= Un vistazo a los estilos de aprendizaje
:hp-tags: e-learning, innovación, estilos de aprendizaje,TIC, educación
:published_at: 2016-07-12

Dentro de las diversas acciones que un docente desarrolla en clase siempre debe tomar en cuenta los divesos estilos de aprendizaje de sus estudiantes, de esta manera podemos asegurar que cada actividad podrá generar un mejor aprendizaje en cada uno de ellos y responder a la diversidad de caracterísiticas de los mismo.

== Estilos de aprendizaje

El emplear metodologías que apunten a mantener como eje central al estudiante deberán tomar en cuenta la heterogeneidad del grupo y trabajar (planificando y aplicado) diversas estrategias didáctiva que permitan justamente que todo el grupo genere un aprendizaje significativo. Para esto imprescindible el proponer actividades direccionadas a sus estilos de aprendizaje, por ello, se revisará algunas de ellas con sus características.

image:https://s20.postimg.org/bt67sp50t/estilos4.png[Estilos de aprendizaje,]

Refiriéndose al tema Laura Frade, articula ocho capacidades que deben tener los docentes, estas capacidades interactúan entre sí para dar como resultado la óptima formación de los estudiantes:

1. Capacidad diagnóstica: capacidad de detectar las necesidades de aprendizaje del estudiante, alienearla a un estilo de aprendizaje y vincularla con una estrategia de aprendizaje.

2. Capacidad cognitiva: capacidad que guarda relación con la adquisición del conocimiento necesario para impartir los contenidos temáticos.

3. Capacidad ética: capacidad que incide en la toma de decisiones del docente sobre su compromiso ante la sociedad, la responsabilidad de trabajo, los valores que promoverá, los juicios de  valor que emitirá, la priorización del desarrollo de los estudiantes, la preocupación sobre su futuro laboral.

4. Capacidad lógica: capacidad para organizar el contenido temáticos de forma lógica-secuencial. Se demuestra por su, orden, graduación y dosificación.

5. Capacidad empática: capacidad que permite entender a los estudiantes en tres diferentes planos: afectivo, cognitivo y psicomotriz.

6. Capacidad comunicativa: habilidad para lograr la mediación entre el aprendizaje y la enseñanza.Se evidencia en el uso de los diferentes tipos de lenguaje que posibiliten al estudiante apropiarse del conocimiento y hacer su propia construcción significativa, lo que les permitirá aprender para la vida.

7. Capacidad lúdica: capacidad que permite diseñar y aplicar diversas estrategias de enseñanza-aprendizaje.

8. Capacidad metacognitiva: capacidad para evaluar el proceso enseñanza-aprendizaje en dos vías: hacia los alumnos verificando avances y estableciendo medidas correctivas, pero además hacia su propio desempeño como docente, lo que le permitirá mejorar día a día en su profesión.

Si nosotros como docentes contamos con estas habilidades, aseguraremos un buen trabajo con nuestros estudiantes.

=== ¿Qué son?

Se definen como las distintas maneras en que un individuo puede aprender; para Alonso y Gallego (1994) los estilos de aprendizaje son los rasgos cognitivos, afectivos y fisiológicos que sirven como indicadores relativamente estables de cómo los alumnos perciben interacciones y responden a sus ambientes de aprendizaje.

Se cree que todas las personas emplean un método particular de interacción, aceptación y procesado de estímulos e información. Las características sobre estilo de aprendizaje suelen formar parte de cualquier informe psicopedagógico que se elabore sobre un estudiante, y debiera ser el fundamento de las estrategias didácticas y refuerzos pedagógicos para que estos sean los más adecuados para el alumno.

Los diversos investigadores que han propuesto algún estilo de aprendizaje en cierto difieren de los componentes de los estilos de aprendizaje; sin embargo estos serían algunos de los más empleados:

* Condiciones ambientales
* Bagaje cultural
* Edad
* Preferencias de agrupamiento (se refiere a si se trabaja mejor individual-
mente o en equipo)
* Estilo seguido para la resolución de problemas
* Tipo de motivación, locus de control interno o externo

El analizar los diferentes estilos de aprendizjae que tienen nuestros estudiantes sin lugar a dudas permitirá que podamos tomar decisiones dirigidas a satisfacer cada necesidad singular en el grupo y con ellos que el conjunto de estudiantes logre la asimilización de conocimientos planificiada o quizás una superior.

=== Clasificación

Los modelos existentes sobre estilos de aprendizaje ofrecen un marco conceptual para entender los comportamientos observados en el aula, los cuales brindan una
explicación sobre la relación de esos comportamientos con la forma en que están aprendiendo los alumnos y el tipo de estrategias de enseñanza que pueden resultar más eficaces en un momento determinado, ya sea por el contendido temático en sí, o bien por las diversas interacciones sociales que se desarrollan en el aula.

De esta manera tenemos varias clasificaciones las cuales se muestran en la siguiente tabla:

image:https://s20.postimg.org/6t8rkqze5/estilos1.png[Calsificación estilos de apredizaje, 800,400 role=right]

=== Modelo de Kolb

El aprendizaje experiencial progresa a través de un ciclo de actividades a las que se conoce habitualmente como ciclo de aprendizaje de Kolb (David Kolb, 1984).

El ciclo tiene cuatro componentes, cada uno de los cuales plantea retos concretos a la hora de planificar actividades académicas.

image:http://image.slidesharecdn.com/estilos-de-aprendizaje-k-o-l-b2165/95/estilos-de-aprendizaje-k-o-l-b-5-728.jpg [ciclos modelo kolb]

Acorde este modelo una persona sulee establecer su estilo de aprendizaje en 1 o máximo 2 de estas fases y de esta menera podemos clasificar a nuestros estudiantes acorde la fase que prefieran trabajar.

* Activo
* Reflexivo
* Teórico
* Pragmático

=== Caráterísticas de cada estilo

Para lograr proponer/emplear estrategias de aprendizaje apropiadas para cada estilo revisemos las características de cada uno:

[cols="1,2,1,1", options="header,footer,autowidth"]
.Características Estilos de parendizaje modelo Kolb
|===
Estilo |Característica General |Cuando facilita el aprendizaje  |Cuando NO facilita el aprendizaje.
|Activos

|Se involucran totalmente y sin prejuicios en las experiencias nuevas.
Disfrutan el momento y cada acontecimiiento. Entusiastas ente lo nuevo. Actuan primero y luego piensan en las consecuencias. Disfrutan trabajando en equipo siendo el eje del grupo. Les aburre planificar a largo plazo y consolidar poryectos.
*La pregunta que buscan responder en el aprendizaje es: _¿Cómo?_*

|Plantendo actividades desafiantes . Actividades de resultados immediatos o a corto plazo. Actividades activas de emoción, drama, acción.

|Siendo pasivos. Demasiado análisis de un tema o mucha reflexión sobre algo. Trabajo individual.

|Reflexivo

|Adoptan una postura observadora de análsis en base a datos, experiencias desde varias perpectivas.Establecen conclusiones en base a argumentos sólidos y convincentes. Son precavidos y analizan todas las implicaciones de cualquier acción antes de ponerse en
movimiento. En las reuniones observan y escuchan antes de hablar procurando pasar desapercibidos. *La pregunta que quieren responder con el aprendizaje es: _¿Por qué?_*

|Cuando pueden tener una postura de observador. Analizar situaciones. Se les facilita información o datos. Tienen tiempo para reflexionar antes de actuar.

|Se exigen ser centro o eje de atención. Actividades de solución inmediata. Improvisación sobre algo. Actividades que le apresuren.

|Teóricos

|Adaptan e intergran las teorías o fundamentos de forma lógica. Organizan las cosas de forma secuencial, integrada y coherente. Analizan y sintetizan información de forma racional. No son subjetivos ni ilógicos. *La pregutna que quieren responder es: _¿Qué?_*

|Cuando se parte de teorías, modelos, sistemas. Ideas o conceptos desafiantes. Actividades que propicien la indagación o cuestionamientos.

|Actividades abiguas o que generen incertidumbre. Actividades/situaciones que prioricen sentimientos o emociones. Cuando no se les facilita la teoría o bases conceptuales.

|Prágmáticos

|Gustan de poner en práctica las ideas, teorías, técnicas nuevas y verificar su funcionamiento, forma de uso/aplicación. Generan/buscan ideas y las ejecutan inmediatamente. Se basan en la realidad para plantear alternativas a fin de de tomar decisiones sobre algo. Buscan desafíos, replantear algo con una diferente perspectiva. Discuten un tema brevemenete, les aburren los debates largos. *La pregunta que quieren responder es: _¿Qué pasaría si?_*

|Actividades que enlacen la teoría con la práctica. Visualizan trabajo/movimiento/acción. Posibilidad de aplicación de algo aprendido.

|Cuando todo queda en teoría. Lo aprendido no se vincula con la realidad o necesidades puntuales. Actividades que no se identifique una finalidad con claridad.

|===

NOTE: Bibliografía

Dra. Lourdes Galeana (2007). Aprendizaje Basado en proyectos. Universidad de Colima. http://goo.gl/wzvMrG

Maria Victoria González Clavero (2011). Estilos de aprendizaje y su influencia para aprender a aprender. Universidad Central “Marta Abreu” de Las Villas. Santa - Cuba. mariag@uclv.edu.cu http://goo.gl/fuDZPb

Secretaría de Educación Pública - México (2005). Manual de estilos de aprendizaje, Material autoinstitucional para docentes y orientadores educativos. http://goo.gl/ZAeldY

John Stephenson, Albert Sangrà (2009). Fundamentos del diseño técnico-pedagógico en e-learning. https://goo.gl/BGAm5A