CLI: add project name and version

[FroMage]

Description

In order to do my CLI plugin which creates packages for Debian or RPM, I need to be able to access the project's name and version.

The current QuarkusProject API doesn't contain this info. Could we add it?

Implementation ideas

No response

[quarkus-bot]

/cc @ebullient (cli), @maxandersen (cli)

[FroMage]

@aloubyansky said it could be done.

[ebullient]

#29379 -- like this?

[aloubyansky]

No, this is about a project in which the CLI is executing a command. The challenge is to do that efficiently for Gradle projects. If we add it to QuarkusProject and it's "expensive" to provide this info it will affect all the commands including those that don't consume this info.

[maxandersen]

How about we generate a json that gets updated by quarkus dev to store things that are semi static like this so you only pay the cost lazily ?

[iocanel]

No, this is about a project in which the CLI is executing a command. The challenge is to do that efficiently for Gradle projects. If we add it to QuarkusProject and it's "expensive" to provide this info it will affect all the commands including those that don't consume this info.

I am not 100% sure on why is it expensive for gralde projects to get the name and version. So, I am talking out loud in hope that someone will correct me.

Let's start with name:

• name is optional in build.gradle and fallback to directory name.
• name can use placeholders with values provided in settings.gralde or global settings.gralde.

And for version:

• version is optional and fallback to the value unspecified.
• version can be specified via allprojects.
• version can use placeholders with values provided in settings.gralde or global settings.gralde.

It doesn't seem like a huge amount of work to get the QuarkusProjectHelper fetch these.

[aloubyansky]

As long as there is no expectation for us to provide accurate info but the best effort then yes, there are options.
AFAIK, the official Gradle way to obtain this info would be to use the Gradle tooling API, which interprets the scripts and relevant configs.

[iocanel]

@aloubyansky: Initially bringing the gradle api to devtools common didn't seem like a good idea to me, but we do bring the maven api, already. wdyt? Shall we bring in the gradle api or go with best effort?

[aloubyansky]

One difference is that the Maven resolver API is used to communicate with the registry in both Maven and Gradle projects. The other one is that with Maven API we can analyze projects "from outside", i.e. w/o requiring to launch a Maven process. The Gradle tooling API is different in that regard, which is why normally we don't bother using it preferring to invoke a Gradle task.
Otherwise, basically, the Gradle API is added where it matters. So the answer would be if there is a place that needs it, we should add it there.