I agree, both approaches are used and I haven't seen any issues related to it.
If we want to change it, that's fine, we can create an issue to track the work but I don't think it is a blocker for this release. +1 JL -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Sun, Aug 4, 2024 at 1:37 PM Christopher Shannon < christopher.l.shan...@gmail.com> wrote: > I won't have a chance to review the release until probably Tuesday but I > wanted to comment on the BOM issue. > > I believe either the approach with ${project.version} or hard coding a > version is fine (as long as you don't use a custom property as the release > plugin won' work). I don't think we need to change the BOM with how it is > currently constructed. > > I have used ${project.version} before in my own BOMs and I haven't had any > issue to note, everything works fine. I also did some research and there's > really nothing I can find that says it is bad practice. As long as the > ActiveMQ parent pom is available it should work as the version is hard > coded for that. > > I've also seen other projects use hard coded versions, but I would also > point out that the two examples listed are actually generated. Spring uses > gradle and Camel has their own maven plugin to generate a bom. If we wanted > to go the specific version route, I am pretty sure we could use hard coded > versions for all of the dependencies in our bom and the release plugin will > handle it. We also could just switch to generating a bom like camel does. > > So TLDR: in my opinion, I think we just keep using what we have with > ${project.version} and if there's an issue that comes up we can change to > generating a bom or hard coding and release plugin management. > > On Sat, Aug 3, 2024, 1:20 PM Matt Pavlovich <mattr...@gmail.com> wrote: > > > Hi JB- > > > > Unfortunately, I believe I need to -1 on this. > > > > I believe the current best practice for bom is to have a fixed version, > > instead of ${project.version}. > > > > See Camel: > > > > > https://repo1.maven.org/maven2/org/apache/camel/camel-bom/4.7.0/camel-bom-4.7.0.pom > > > > See Spring: > > > > > https://repo1.maven.org/maven2/org/springframework/spring-framework-bom/6.1.11/spring-framework-bom-6.1.11.pom > > > > -Matt Pavlovich > > > > > On Aug 2, 2024, at 1:50 AM, Jean-Baptiste Onofré <j...@nanthrax.net> > > wrote: > > > > > > Hi everyone, > > > > > > I submit Apache ActiveMQ Classic 6.1.3 release to your vote. > > > > > > This release includes 16 fixes and updates, especially: > > > - add a BoM > > > - fixes on the Message REST API, especially concurrent access > > > - Spring 6.1.11 update > > > - fix NoClassDefFound on bin/activemq export command line > > > - several dependency updates > > > > > > You can take a look on Release Notes for details: > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12354559 > > > > > > Maven Staging Repository: > > > > > > https://repository.apache.org/content/repositories/orgapacheactivemq-1400/ > > > > > > Dist Staging Repository: > > > https://dist.apache.org/repos/dist/dev/activemq/activemq/6.1.3/ > > > > > > Git tag: activemq-6.1.3 > > > > > > Please vote to approve this release: > > > [ ] +1 Approve the release > > > [ ] 0 I don't care > > > [ ] -1 Don't approve the release (please provide specific comment) > > > > > > This vote will be open for at least 72 hours. > > > > > > Thanks! > > > Regards > > > JB > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org > > > For additional commands, e-mail: dev-h...@activemq.apache.org > > > For further information, visit: https://activemq.apache.org/contact > > > > > > > > > > >
