Replace Gradle's deprecated buildIdentifier.getName() with newer API

[Eng-Fouad]

buildIdentifier.getName() is deprecated since Gradle 8.2 and will be removed in the next release Gradle 9.0.

* @deprecated Use {@link #getBuildPath()} instead.
     */
    @Deprecated
    String getName();

[Eng-Fouad]

I think this if-statement should be updated:

https://github.com/Eng-Fouad/quarkus/blob/b9ba83d8faa888f056df0ae1b5da3efd99d90c89/devtools/gradle/gradle-model/src/main/java/io/quarkus/gradle/tooling/ToolingUtils.java#L57-L60

if (ib.getName().equals(buildPath)) {
    return ib;
}

Previously it was:

if (ib.getName().equals(buildName)) {
    return ib;
}

and I am not sure how the values of buildPath and buildName look like:

/**
     * Absolute build path of the build within the Gradle invocation.
     *
     * @since 8.2
     */
    String getBuildPath();

    /**
     * The name of the build.
     *
     * @deprecated Use {@link #getBuildPath()} instead.
     */
    @Deprecated
    String getName();

Is it like this?

buildPath = /opt/myproject/subproject1/build
buildName = subproject1

cc @aloubyansky

[Eng-Fouad]

This resolves #39221 as well.

[maxandersen]

i've seen a few of these "xyz deprecated in version something of gradle" - is any of this changing the base version of gradle we say Quarkus work with? do we keep track of it so we don't surprise users with breaking things by surprise?

[Eng-Fouad]

i've seen a few of these "xyz deprecated in version something of gradle" - is any of this changing the base version of gradle we say Quarkus work with? do we keep track of it so we don't surprise users with breaking things by surprise?

I am not sure. The Gradle guide does not mention any minimum supported Gradle versions.

cc @gsmet @geoand @aloubyansky

[wolfs]

Is it like this?

buildPath = /opt/myproject/subproject1/build
buildName = subproject1

No, the absolute build path means the path within a composite build. So the root build has name : (I think) and buildPath :. In included build logic build might have build path :build-logic and build name build-logic. Finally, if a included build includes a build logic build the build path would be :included-build:build-logic and the build name would be build-logic.

In general, the absolute build path is a unique identifier of an (included) build in a Gradle invocation, while the build name is not.

[Eng-Fouad]

Is it like this?

buildPath = /opt/myproject/subproject1/build
buildName = subproject1

No, the absolute build path means the path within a composite build. So the root build has name : (I think) and buildPath :. In included build logic build might have build path :build-logic and build name build-logic. Finally, if a included build includes a build logic build the build path would be :included-build:build-logic and the build name would be build-logic.

In general, the absolute build path is a unique identifier of an (included) build in a Gradle invocation, while the build name is not.

So, is this implementation correct?

if ((":" + ib.getName()).equals(buildPath)) {
    return ib;
}

// or maybe
if (buildPath).endsWith((":" + ib.getName())) {
    return ib;
}

Alternatively, we can use (not sure if it is valid for all cases):

if (((DefaultIncludedBuild) ib).getBuildIdentifier().getBuildPath().equals(buildPath)) {
    return ib;
}

or

if (((IncludedBuildInternal) ib).getTarget().getBuildIdentifier().getBuildPath().equals(buildPath)) {
    return ib;
}

[wolfs]

This might work some of the time. What I don't understand is why you try to obtain the instance of the included build in the first place. What is the code trying to achieve and can that be achieved on the dependency level alone without reaching into other configured projects or included builds.

[Eng-Fouad]

This might work some of the time. What I don't understand is why you try to obtain the instance of the included build in the first place. What is the code trying to achieve and can that be achieved on the dependency level alone without reaching into other configured projects or included builds.

The code existed before. I am just trying to replace deprecated methods that will be removed in the next release Gradle 9.0.

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 9000916.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

[aloubyansky]

Thanks a lot @Eng-Fouad!

[aloubyansky]

@wolfs thanks for your advises here. For now, we need to be able to discover project sources for certain launch modes. If there is a better way of doing that, please let us know. Thanks!