Support simple way to override/define the client version

[timonzi]

As you mentioned in #402, we can/should define the Artemis client version ourselves - normally by using the same version as for the broker.

It would be good to have a simple way to set the client version instead of overriding the dependency management (with all the exclusions) as described in this comment. For example: I don't know what exclusions might be required for an older or future client version.

It would be nice so have the possibility to set for example a Maven property which defines the client version. Also the import of a POM definition, which has the correct configuration per client could be a possibility.

[turing85]

Some notes on this:

• We'd want to have at least somewhat of a history for older versions of the driver. Looking at the releases at mvnrepository.com, maybe back to version 2.20.0
• Whenever a new version of artemis is released, we need to build a new version of the bom
• It would be ideal if the bom were maintained and released by activemq-artemis (github.com), @middagj, @zhfeng do you have contact to the artemis-team? Maybe they are willing to provide the bom.

[zhfeng]

I think there is https://github.com/apache/activemq-artemis/blob/main/artemis-bom/pom.xml just be added recently. Is it what you are expecting?

[middagj]

Yes, looks like it. I don't have any contacts with Artemis.

[timonzi]

Is there any news on the subject? During the last update to Quarkus 3.8.6 and the corresponding Quarkus Artemis extension, we had a relatively high effort because we also updated the broker version on our environments. That's why I'm thinking about leaving the broker version on the current version when we do the next Quarkus update. And then the client version should also match the broker version.

[middagj]

They seems to have published a bom package: https://central.sonatype.com/artifact/org.apache.activemq/artemis-bom/versions. Does this work for you?

I think we should also switch to use the bom.

[timonzi]

We have not yet tested this because we are currently still using version 2.32.0. If you say that this is the definition that you can/will use in the future, then I think that would be a viable way for us to overwrite the client version.
If we want to stay on the current version (2.32.0), then we will have to think about something else (maybe something like described in #402 (comment)).

[middagj]

Ah yes, 2.32 is not released. Not reinventing the wheel always have my strong preference. If we publish a bom ourselves for older versions, preferably it should include all Artemis dependencies, and you only have a single shot (if you don't want to subversion the Artemis version).

Best would be to use the workaround described and switch the Artemis bom when you upgrade Artemis again. I tested it with the integration tests and it works as it should.

[timonzi]

After reading you comment (which I didn't understand completely) and checking your changes I'm not really sure how the definition of the client version would look like. Maybe I was also a bit too fast with my last comment, as I didn't check the content of the referenced BOM and I don't have a complete overview of this topic at the moment.

So when I set the dependency management like described in the documentation:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>io.quarkus.platform</groupId>
            <artifactId>quarkus-bom</artifactId>
            <version>3.16.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
        <dependency>
            <groupId>io.quarkiverse.artemis</groupId>
            <artifactId>quarkus-artemis-bom</artifactId>
            <version>3.6.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

How would I achieve to use a different Artemis client version, like for example 2.33.0? When I would add the following entry in the dependency management, it would define the versions for the Artemis dependencies, but in you quarkus-artemis-bom you would define the dependencies like artemis-core-client again (with the exclusions), but here a different version (defined via ${artemis.version}) is used and your exclusions would not be used, right?

<dependency>
    <groupId>org.apache.activemq</groupId>
    <artifactId>artemis-bom</artifactId>
    <version>${different.artemis.client.version}</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>

Or would everything work when I override the property artemis.version and use this also for the artemis-bom? But this would have no effect, like in described in #402 (comment), right?
Maybe there is a misunderstanding from my site and I have to check our previous discussions and get into the topic again.

[middagj]

I need to double check, but my first impression was that the dependencies are merged so our exclusions and the version from the Artemis bom are combined.

The rest of the comment is more about the older versions for which I would just apply the workaround as in #402 (comment) until you switch to a newer version.

[turing85]

@all-contributors please add @timonzi for ideas

[allcontributors]

@turing85

I've put up a pull request to add @timonzi! 🎉

[turing85]

@timonzi We merged #679. I would like to wait a little bit longer for the release (we updated the artemis-jms library to version 2.38.0, but the corresponding container image hasn't been built yet, I'd like those two versions to match). I'll ping you again as soon as the improvement has been release. It will be avialable in version 3.6.x and 3.5.x.