Hi Claus,
Thanks, good info. I’ll follow the same for ActiveMQ.
-Matt Pavlovich
> On Mar 13, 2024, at 1:29 AM, Claus Ibsen wrote:
>
> Hi
>
> The BOM should use hardcoded versions as the BOM is for a given version, eg
> 4.5.0 should be 4.5.0 versions.
> That is also what everyone else is doing also. If you want to use a
> different Camel version you refer to that BOM version, i.e. 4.6.0 and so on.
>
> For example SB has 3.2.3 hardcoded in their 3.2.3 BOM file
> https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-dependencies/3.2.3/spring-boot-dependencies-3.2.3.pom
>
>
>
> On Tue, Mar 12, 2024 at 2:45 PM Matt Pavlovich wrote:
>
>> Hi Claus-
>>
>> Question: I’m planning to update some BOMs for other projects and was
>> wondering if there were other reasons to use a hard-coded value vs a
>> property? I agree, using ${project.version} is not going to work for a bom.
>>
>> Would using a declared property such as ${apache.camel.version} have any
>> unintended side-effects?
>>
>> Thanks,
>> Matt Pavlovich
>>
>>> On Mar 10, 2024, at 7:34 AM, Claus Ibsen wrote:
>>>
>>> Hi
>>>
>>> https://issues.apache.org/jira/browse/CAMEL-20413
>>>
>>> The BOM we release for both core and SB have
>>>
>>>
>>> org.apache.camel
>>> camel-api
>>> ${project.version}
>>>
>>>
>>> But they should use the hardcoded release version, eg:
>>>
>>>
>>> org.apache.camel
>>> camel-api
>>> 4.4.0
>>>
>>>
>>> If you look what we do now its wrong
>>>
>> https://repo1.maven.org/maven2/org/apache/camel/camel-bom/4.4.0/camel-bom-4.4.0.pom
>>>
>>> This PR fixes camel-bom
>>> https://github.com/apache/camel/pull/13432
>>>
>>> Then we also need a fix for camel-spring-boot BOM as well
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -
>>> @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
>>
>>
>
> --
> Claus Ibsen
> -
> @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2