So I will preface this by saying hopefully my comments are not taken the wrong way and turn into a big fight but instead can lead to a productive discussion about the next steps.
First, I'm certainly not opposed to anyone who wants to work on modernizing and adding features to existing software. It is after all community driven so if there are people willing to do the work then go for it. I myself am a heavy user still of 5.x and some of those features could be useful and intriguing if they were ultimately implemented. They are quite major features so it would require a lot of people/work to actually make it a reality. However...The main focus has generally been to maintain 5.x (bug fixes, small features etc) and keep it around but to work on modernizing AMQ by going with Artemis as the next generation. There's been work to add feature parity (still on going) in order to promote it as the future broker that people would move to when ready. Our new website even describes Artemis as the next generation etc with the intention for people to ultimately migrate. My primary concern here is that putting resources and effort into a major upgrade of 5.x will just create further divide in the AMQ community and you will just end up with one faction focused on 5.x and one on Artemis and divide up resources vs putting resources towards one ultimate broker. I think that in this scenario it would be somewhat counterproductive to be essentially competing against ourselves with 2 brokers working to be modernized under the same project (not to mention confusing for users). So personally I think it would be more beneficial if the community would work towards one future broker (Artemis) to improve it vs trying to modernize 2 brokers. Why not take the effort that would be put towards modernizing 5.x into Artemis instead so we have 1 ultimate next generation broker? However, again, this is community driven so if there's enough support to modernize 5.x then it certainly can be done. But that leads me to a discussion that I have been hesitant to bring up but is this...if there is enough support to want to go with 5.x modernization and put significant resources towards it then I feel like it might finally be time to split up the community and have AMQ and Artemis go their separate ways so they each can thrive in their own environment and not have to deal with competing groups stepping on each other. On Tue, Jun 18, 2019 at 11:44 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi all, > > I would like to discuss with you about the ActiveMQ 5.x roadmap. > > Even if Artemis is there, the stack is different and we still have lot > of users on ActiveMQ, and, as a ActiveMQ 5.x fan and contributor, I > think it's worth to give a new "dimension" to ActiveMQ 5.x. > > As all Apache projects, ActiveMQ 5.x roadmap and use is driven by the > community, so I would like to propose and share some ideas with the > ActiveMQ community. > > I already imagine a new codename for ActiveMQ 5.x roadmap: ActiveMQ Missus. > > Basically, I would like to propose a roadmap around three major points: > > 1. Modularity > Today, ActiveMQ 5.x is a monolythic broker, even if most of the parts > are already well isolated (persistent stores, transport connectors, > etc). It makes sense to have some more "modular" and micro-services > oriented, why not leveraging Apache Karaf with services. > > 2. Configuration backends > We currently use Spring beans XML as main configuration backend (or > blueprint in Karaf). I think it makes sense to update and split the > configuration backend with something more "pluggable", and be able to > expose new configuration format like yml. > > 3. Protocol/API update > I would like to add support of JMS 2.0 in ActiveMQ 5.x and check/update > the other protocols/APIs. > > 4. Cloud friendly > I already sent some ideas weeks ago about "cloud friendly features" in > ActiveMQ 5.x. > Basically, I would like to propose: > - a replicated/distributed persistent store to be able to have several > brokers running with a distributed store. I'm testing an update to > KahaDB using Bookkeeper. > - provide new discovery agents with support of Kubernetes, Hazelcast, ... > > I would love to hear the community about this ! ;) > I'm planning to start a complete document to provide more details and > "milestone". > > Thoughts ? > > Regards > JB > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
