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

----
$ gradle buildEnvironment
----

====

The output of the task clearly indicates the classpath of the `classpath` configuration:

----
$ gradle buildEnvironment
include::{snippetsPath}/developingPlugins/externalLibraries/tests/buildEnvironment.out[]
----

A Gradle plugin does not run in its own, isolated classloader, so you must consider whether you truly need a library or if a simpler solution suffices.

        settingsScript """
            includeBuild 'ext-lib'
            includeBuild 'build-logic'
        """
        buildScript "plugins { id 'my-plugin' }"

        when:
        succeeds 'buildEnvironment'

        then: "build logic classpath doesn't contain external dependency"
        outputDoesNotContain('com.acme:ext')

        and: "worker action uses external dependency"
        succeeds 'runAction'

// 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.

[[build_environment]]
= Configuring the Build Environment

Configuring the build environment is a powerful way to customize the build process.
There are many mechanisms available.

The full list of built-in tasks that should not be replaced is:
`wrapper`, `init`, `help`, `tasks`, `projects`, `buildEnvironment`, `components`, `dependencies`, `dependencyInsight`, `dependentComponents`, `model`, `properties`.

[[changes_4.7]]
== Upgrading from 4.6 and earlier

=== Potential breaking changes

include::sample[dir="groovy",files="build.gradle[]"]
====

The `login` task declares an input property and connects it with a credentials provider.
The credentials provider will fetch the credentials pieces from the link:{userManualPath}/build_environment.html#sec:project_properties[project properties].

Credentials can be passed to a task in multiple ways:

 * via command-line properties:
=====
----

This sample shows how credentials can be used when publishing artifacts to a Maven repository using link:{userManualPath}/build_environment.html#sec:project_properties[project properties].
This approach allows you to keep sensitive configuration out of your project's source code and inject it only when needed.

<6> JDKs downloaded by the <<toolchains.adoc#sec:provisioning, toolchain support>>.
<7> Distributions downloaded by the <<gradle_wrapper.adoc#gradle_wrapper_reference,Gradle Wrapper>>.
<8> Global <<build_environment.adoc#sec:gradle_configuration_properties,Gradle configuration properties>>.

Consult the <<directory_layout.adoc#dir:gradle_user_home,Gradle Directories reference>> to learn more.

[[project_root]]

# Gradle settings configured through the IDE *will override*
# any settings specified in this file.
# For more details on how to configure your build environment visit
# http://www.gradle.org/docs/current/userguide/build_environment.html
# Specifies the JVM arguments used for the daemon process.
# The setting is particularly useful for tweaking memory settings.
org.gradle.jvmargs=-Xmx1536m
# When configured, Gradle will run in incubating parallel mode.

You can enable configuration-on-demand using the `--configure-on-demand` flag or adding `org.gradle.configureondemand=true` to the `gradle.properties` file.

To configure on demand with every build run, see <<build_environment.adoc#sec:gradle_configuration_properties,Gradle properties>>.

To configure on demand for a given build, see <<command_line_interface.adoc#sec:command_line_performance,command-line performance-oriented options>>.