This message was deleted Gradle Community #dependency-management

Join Slack

This message was deleted.

# dependency-management

Slackbot

10/18/2023, 1:10 AM

This message was deleted.

Ryan Schmitt

10/18/2023, 1:11 AM

CC @Rooz this is a good example of a stability concern I have

Vampire

10/18/2023, 1:25 AM

Isn't this a little hasty

Well, the backward compatibility policy is:

Once deprecated, it may be removed in the next major release. Deprecated features may be supported across major releases, but this is not guaranteed.

So even if something is deprecated in the last hotfix of a major version, it can be removed right in the next release. If you have concerns that it is too hasty for this case, you should probably open an issue on GitHub with them. Wouldn't be the first deprecation for which the removal gets shifted to a later major release. 🙂

was still in the Gradle documentation as recently as 8.1? The documentation has only been correct since 8.2,

I don't really get what you mean. The link you posted first follows to the upgrade guide section "upgrading from 8.1", so this change was indeed made in 8.2. So if 8.2 documentation also had those idioms removed, there was nothing to "correct", because in 8.1 it was not yet deprecated.

ephemient

10/18/2023, 1:27 AM

even if the documentation was out of date, I believe the deprecation warning has been in place since 8.0

Vampire

10/18/2023, 1:28 AM

Oh, ok, but rest of my statement holds 😄

ephemient

10/18/2023, 1:30 AM

yep. I think Gradle has done this deprecation reasonably. I don't think https://docs.gradle.org/current/userguide/feature_lifecycle.html promises that it needs to be deprecated for a full major cycle before removal either…

ephemient

10/18/2023, 1:31 AM

just saying that this one really has been a full cycle

Vampire

10/18/2023, 1:31 AM

Yeah, as I quoted above. Even from last hotfix release to directly next release which is major release would fit 🙂

Vampire

10/18/2023, 1:34 AM

Are you sure that deprecation warning was there in 8.0? Or did you maybe see it in some nightly?

Copy code

$ git d b80d1d2d723^! -- subprojects/testing-jvm/src/main/java/org/gradle/api/internal/tasks/testing/detection/ForkedTestClasspathFactory.java
diff --git a/subprojects/testing-jvm/src/main/java/org/gradle/api/internal/tasks/testing/detection/ForkedTestClasspathFactory.java b/subprojects/testing-jvm/src/main/java/org/gradle/api/internal/tasks/testing/detection/ForkedTestClasspathFactory.java
index ead5ae4b0b8..bdd71841317 100644
--- a/subprojects/testing-jvm/src/main/java/org/gradle/api/internal/tasks/testing/detection/ForkedTestClasspathFactory.java
+++ b/subprojects/testing-jvm/src/main/java/org/gradle/api/internal/tasks/testing/detection/ForkedTestClasspathFactory.java
@@ -30,6 +30,7 @@
 import org.gradle.internal.UncheckedException;
 import org.gradle.internal.classpath.ClassPath;
 import org.gradle.internal.classpath.DefaultClassPath;
+import org.gradle.internal.deprecation.DeprecationLogger;
 import org.gradle.util.internal.CollectionUtils;

 import java.io.Closeable;
@@ -122,13 +123,11 @@ private ForkedTestClasspath getClasspathWithAdditionalModules(
         AdditionalClasspath additional,
         boolean isModule
     ) {
-        // TODO #13955: Enable this deprecation in 8.2
-        // We don't have enough time in 8.1 to write the documentation and update our own tests.
-//        DeprecationLogger.deprecateIndirectUsage("The automatic loading of test framework implementation dependencies")
-//            .withAdvice("Declare the desired test framework directly on the test suite or explicitly declare the test framework implementation dependencies on the test's runtime classpath.")
-//            .willBeRemovedInGradle9()
-//            .withUpgradeGuideSection(8, "test_framework_implementation_dependencies")
-//            .nagUser();
+        DeprecationLogger.deprecateIndirectUsage("The automatic loading of test framework implementation dependencies")
+            .withAdvice("Declare the desired test framework directly on the test suite or explicitly declare the test framework implementation dependencies on the test's runtime classpath.")
+            .willBeRemovedInGradle9()
+            .withUpgradeGuideSection(8, "test_framework_implementation_dependencies")
+            .nagUser();

         if (isModule) {
             return new ForkedTestClasspath(
$ git tag --contains b80d1d2d723
v8.2.0
v8.2.0-M1
v8.2.0-RC1
v8.2.0-RC2
v8.2.0-RC3
v8.2.1
v8.3.0
v8.3.0-RC1
v8.3.0-RC2
v8.3.0-RC3
v8.3.0-RC4
v8.4.0
v8.4.0-RC1
v8.4.0-RC2
v8.4.0-RC3
$

ephemient

10/18/2023, 1:41 AM

oh my search included javadoc. I saw https://github.com/gradle/gradle/commit/7d8d058b1a4104615b8a24a6e111b6562bf770f2#diff-fd6f14fe45ac2f17c05fcb9725e81db0385443fa7ee7d8aaaef95280993dbd87 is contained in 8.0 and adds

Copy code

/**
     * Whether the legacy behavior of loading test framework dependencies from the Gradle distribution
     * is enabled. If true, jars and modules as specified by {@link #getTestWorkerImplementationClasses()}
     * and {@link #getTestWorkerImplementationModules()} respectively are loaded from the Gradle distribution
     * and placed on the test worker classpath and/or modulepath.
     * <p>
     * This functionality is legacy and will eventually be deprecated and removed. Test framework dependencies
     * should be managed externally from the Gradle distribution, as is done by test suites.
     *
     * @return Whether test framework implementation dependencies should be loaded from the Gradle distribution.
     */
    @Internal
    boolean getUseImplementationDependencies();

but yeah, that doesn't actually log a warning

ephemient

10/18/2023, 1:42 AM

so it was definitely planned by 8.0, it just didn't get completed until later

👌 1

Open in Slack

Previous Next