Additionally, we’d benefit from centralizing a number of the Buffer, ASCIIBuffer, UTF8Buffer, etc classes into one activemq-io (or similar) module across the project. Currently, there is a lot of redundancy in that area and overall this would be a good housekeeping step to keep core data and buffer classes modernized (we can also look at using Records and/or Carrier Classes (when available).
Thanks, Matt > On Apr 1, 2026, at 5:24 PM, Christopher Shannon > <[email protected]> wrote: > > I'm basically +0 on this as I don't think it really matters. We can move > the code base into the main repo or not but I don't think it matters too > much either way just because of the infrequency of updates. > > If it really is only used by the ActiveMQ project itself then maybe it does > make sense to make it a module like the rest of the project modules. > > > > On Fri, Mar 27, 2026 at 12:35 PM Justin Bertram <[email protected]> wrote: > >> As noted previously, I'm not super familiar with this code and how >> it's used so maybe I'm missing something, but doesn't this library >> simply provide content-agnostic access to what is essentially a byte >> buffer? If so, why would changing the content of the buffer (e.g. for >> new fields moving across the wire or being persisted to storage) >> require changing the API? Do you anticipate adding fundamentally new >> types of data? >> >> Regarding version alignment, this seems pretty straight-forward and >> not really any different from other dependencies. >> >> >> Justin >> >> On Thu, Mar 26, 2026 at 3:05 PM Matt Pavlovich <[email protected]> >> wrote: >>> >>> I agree the code and API will not change frequently. However, when it >> does change it will be more complicated working out of two trees vs having >> one tree to merge a PR — specifically shared subscriptions and other >> modernization ideas — like tracking destination deletes, purges, etc. and >> the proposed work on replication. It would require >> patches/release/alignment or working with SNAPSHOTs when in two repos. >>> >>> I think the work to keep the modernized and secured — maven plugins, JDK >> version alignment, code style, etc.. is all easier as part of the main tree >> vs having a separate repo and release cycle. >>> >>> Version alignment and compatibility becomes harder for users to >> understand intuitively and for us to maintain: >>> activemq-broker-7.0.0 / activemq-protobuf-2.0 >>> activemq-broker-6.3.0 / activemq-protobuf-1.1 >>> >>> There are virtually no consumers referencing the jar itself via maven — >> and the two most prominent ones would pickup the versions naturally by the >> protobuf jar version jumping to match the distro. >>> >>> Flipping the question around— why keep it separate? It is another >> JIRA/repo/issues/PRs etc to track and maintain vs hosting the classes and >> being able to make changes going forward as one-PR to one repo. >>> >>> Matt >>> >>>> On Mar 26, 2026, at 2:43 PM, Christopher Shannon < >> [email protected]> wrote: >>>> >>>> It has been a long time since this came up but it looks like I already >> made >>>> the point on the PR that the protobuf code almost never changes. The >> last >>>> release was done in 2010 so it hasn't been updated in 16 years. >>>> >>>> So my main question is what exactly are you expecting to change that we >>>> would need to be releasing every version or prototyping? >>>> >>>> I certainly expect that we might need to make some changes soon if we >> are >>>> making updates for shared subscriptions or if we want to modernize it, >> but >>>> I would think we'd update the version once and then it probably >> wouldn't >>>> change for another 16 years. >>>> >>>> I'm not necessarily against it per se but I'm just struggling to see >> why we >>>> need to do this and what you expect will be changing frequently enough >> to >>>> justify the move vs keeping it separate and only releasing it when >>>> infrequent updates happen. >>>> >>>> Chris >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Mar 24, 2026 at 10:21 AM Matt Pavlovich <[email protected]> >> wrote: >>>> >>>>> The activemq-protobuf project was split out from the main line >> project a >>>>> while ago and I don’t think it serves the project having it split out. >>>>> >>>>> 1. It is more work to maintain an independent module that is rarely >> used >>>>> by any other project (JDK alignment, Maven modules, release, vote, >> issues, >>>>> etc) >>>>> see: >>>>> >> https://mvnrepository.com/artifact/org.apache.activemq.protobuf/activemq-protobuf/1.1 >>>>> >>>>> Note: The next release would automatically signal an upgrade to any >>>>> consumer of this jar by the version number being higher than the >> current >>>>> >>>>> 2. Having this hosted will allow us to more quickly experiment and >> modify >>>>> the broker for any datastore changes that need to be made— changes to >>>>> activemq-protobuf and other activemq-* modules may need to be merged >>>>> together for feature changes vs ‘guessing’ if a design works in >>>>> activemq-protobuf, releasing and then changing the main broker >> modules. >>>>> >>>>> PR discussion here: >>>>> https://github.com/apache/activemq/pull/1209 >>>>> >>>>> Thanks, >>>>> Matt Pavlovich >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> For further information, visit: https://activemq.apache.org/contact >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> For further information, visit: https://activemq.apache.org/contact >> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information, visit: https://activemq.apache.org/contact
