quarkusio / quarkus

Quarkus: Supersonic Subatomic Java.
https://quarkus.io
Apache License 2.0
13.77k stars 2.68k forks source link

Add a property for the version when creating a project with a non-platform extension #39439

Open ia3andy opened 7 months ago

ia3andy commented 7 months ago

Description

Currently when adding a non-platform extension, the version is hard-coded:

<dependency>
      <groupId>io.quarkiverse.web-bundler</groupId>
      <artifactId>quarkus-web-bundler</artifactId>
      <version>1.3.1</version>
    </dependency>

It would be nice to have the version as a property instead:

...
<properties>
    ....
    <quarkus-web-bundler.version>1.3.0</quarkus-web-bundler.version>
</properties>
...
<dependency>
      <groupId>io.quarkiverse.web-bundler</groupId>
      <artifactId>quarkus-web-bundler</artifactId>
      <version>${quarkus-web-bundler.version}</version>
    </dependency>

I guess this could also be done when adding an extension on an existing project.

Implementation ideas

No response

arvind-vignesh commented 7 months ago

Hey I would like to contribute to this but im a little new to quarkus. If someone can point me in the right direction on where i can possibly start for this, it would be greatly appreciated.

felix-seifert commented 7 months ago

I had a look at this issue and we have two options. Before describing these options, I want to summarise my observations about how extensions are currently added.

For a MavenProjectBuildFile, we have a specific method to add a dependency (with a version). This method receives information on whether this dependency is managed and needs a version. After adding dependencies to the model, it is written as a pom.

My initial idea was to directly set the version as a ref to the respective property when the version is assigned (see following code suggestion).

    private void setDependencyVersionViaProperty(ArtifactCoords coords, Dependency d) {
        final String artifactVersionProperty = d.getArtifactId() + ".version";
        model().addProperty(artifactVersionProperty, coords.getVersion());
        d.setVersion("${" + artifactVersionProperty + "}");
    }

The problem with this approach is that whenever we read the version of a dependency within our DOM, we receive a weird property ref. And as we use an external Maven Model, we cannot just add a function to resolve the version before retrieving it and would have to handle this special case several times.

Without good knowledge of our DOM and already existing solutions, I can see the following two options.

  1. We write a wrapper around the Model of a Maven file. This wrapper class would have the same functionality as the existing class, with the only difference being that it resolves versions of the dependencies before returning them.
  2. The dependency versions would be moved to the properties section right before the pom is written to disk. Then, the versions would be resolved right after reading the pom from disk. This option would have the disadvantage of not keeping the existing formatting of the pom (e.g. versions which are set in-line/not via properties). This is because the model does not have the information if the dependency is managed or not, and would move all dependency versions to the properties section.

Which option do you suggest? Is there maybe an existing solution which I could reuse, or is there another option I did not see?

gauravPanditr commented 2 months ago

please can you assign me

aureamunoz commented 3 days ago

Did you have the time to take a look on this @gauravPanditr ? Is it still relevant?