+
image::intellij-script-dependencies-reload.png[Reload script dependencies]

We recommend that you _disable automatic build import_, but _enable automatic reloading of script dependencies_.
That way you get early feedback while editing Gradle scripts and control over when the whole build setup gets synchronized with your IDE.

=== Troubleshooting

The IDE support is provided by two components:

Previously, this logic would have omitted the two above noted attributes entirely, while now the same logic will copy the attributes and finalize the project's Java toolchain.
To avoid early toolchain finalization, attribute-copying logic should be updated to query the source Configuration's attributes lazily:

=====
[.multi-language-sample]
======
.build.gradle.kts
[source,kotlin]
----

// See the License for the specific language governing permissions and
// limitations under the License.

[[working_with_files]]
= Working With Files

File operations are fundamental to nearly every Gradle build.
They involve handling source files, managing file dependencies, and generating reports.
Gradle provides a robust API that simplifies these operations, enabling developers to perform necessary file tasks easily.

[[config_cache:stable]]
== Stable configuration cache

Working towards the stabilization of configuration caching we implemented some strictness behind a feature flag when it was considered too disruptive for early adopters.

You can enable that feature flag as follows:

====
include::sample[dir="snippets/configurationCache/stableFeatureFlag/kotlin",files="settings.gradle.kts[]"]

Another common step is to attach all the unit test dependencies to the integration tests as well — via `intTestImplementation.extendsFrom testImplementation` — but that only makes sense if the integration tests require _all_ or nearly all the same dependencies that the unit tests have.

There are a couple of other facets of the example you should take note of:

Alternatively, you might want to enable verification on CI servers but not on local machines.

Gradle actually provides 3 different verification modes:

- `strict`, which is the default.
Verification fails _as early as possible_, in order to avoid the use of compromised dependencies during the build.
- `lenient`, which will run the build even if there are verification failures.