I'm +0 on this as well. My concerns are rooted in not understanding the technical (i.e. code) reasons for needing/wanting this. My apologies if I've held up your progress needlessly.
Justin On Thu, Apr 2, 2026 at 9:39 AM Matt Pavlovich <[email protected]> wrote: > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information, visit: https://activemq.apache.org/contact
