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 > > >
