Dev list got dropped so adding back in (really this probably only belongs the dev list anyways)
On Thu, Jul 11, 2019 at 12:08 PM Christopher Shannon < christopher.l.shan...@gmail.com> wrote: > Many of those pull requests are years old. Furthermore no one is saying > there is no interest in a project. But there is a huge difference from > supporting 5.x in terms of bug fixes and small features than talking about > doing something like adding new protocols or JMS 2.0 support. For example > the level of effort to add JMS 2.0 correctly is quite high and I highly > doubt there's going to be anyone to do the work. You need to update > everything from the client libraries to the broker logic all the way to the > data store (KahaDB) etc. > > Doing something like that is a massive undertaking and makes 0 sense to me > at this point. Why would we add JMS 2.0 support to 5.x when we already > have Artemis that supports JMS 2.0 and as a project we had previously > agreed to work towards Artemis as the next generation broker and as the > follow on? And yes we had established that fact already as a project and > it's already on our website etc. If someone has enough time to try and add > JMS 2.0 to 5.x then why not use that time to help make Artemis a drop in > replacement or make it easier to upgrade? Bruce brought that up and I do > think that having a drop in replacement should still be a goal or at least > close to it. We want to be able to make the upgrade process as easy as > possible for people. > > As I mentioned in my initial response I just don't think it makes any > sense to start adding major new features to what is supposed to be a legacy > broker as we decided to make Artemis the next generation when it was > ready. And if people want to go down that path I don't see how it benefits > either project to do it concurrently under the same umbrella and have > competing brokers. > > On Thu, Jul 11, 2019 at 11:27 AM Bruce Snyder <bruce.sny...@gmail.com> > wrote: > >> (Reposting in this roadmap discussion) >> >> I agree that we must define a clear roadmap. We should create a new wiki >> page for an overall ActiveMQ project roadmap that includes info for all >> the >> ActiveMQ components (ActiveMQ, ActiveMQ Artemis, ActiveMQ NMS and ActiveMQ >> CMS). There is already an ActiveMQ Artemis Roadmap wiki page, is this info >> still relevant/usable ( >> >> https://cwiki.apache.org/confluence/display/ACTIVEMQ/ActiveMQ+Artemis+Roadmap >> )? >> >> We need to work openly via the dev@activemq list on this roadmap page so >> that it is defined in the open, is unambiguous and includes the entire >> ActiveMQ community. It's very important that we hear from users of each >> component because these folks have various ActiveMQ components deployed in >> production and we need to know what is important to them instead of >> speaking for them. >> >> As part of the roadmap discussion, we must also decide if one of the goals >> for Artemis is still to be a drop-in replacement for ActiveMQ. I know that >> at one time this was the goal, i.e., allow current ActiveMQ users to drop >> in Artemis and have everything just continue to work. Is there still value >> in this goal? >> >> Bruce >> >> On Thu, Jul 11, 2019 at 1:37 AM <michael.andre.pea...@me.com.invalid> >> wrote: >> >> > Its about having clear direction as a project. Im not saying it has to >> be >> > artemis im not saying it has to be classic >> > >> > >> > >> > >> > But there does have to be a single and very clear direction so end users >> > have a clear understanding in the long term direction. >> > >> > >> > >> > >> > Having ever changing direction is worse than having none at all also. >> It >> > actually has a negative impact. >> > >> > >> > >> > >> > >> > >> > This said last year i thought a clear direction was agreed. But if that >> is >> > to change, i think we need to be very clear what that is for both >> classic, >> > artemis and the clients. With actual real commitments, not just wooly >> > aspirational ideas. >> > >> > >> > >> > >> > Get Outlook for Android >> > >> > >> > >> > >> > >> > >> > >> > On Thu, Jul 11, 2019 at 7:59 AM +0100, "Francois Papon" < >> > francois.pa...@openobject.fr> wrote: >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > Hi, >> > >> > We can a see there is still an interest from the users to Apache >> > ActiveMQ 5.x. >> > >> > In github we have 61 open PR => >> https://github.com/apache/activemq/pulls >> > >> > Why forcing users to migrate to Artemis if the community is still >> active? >> > >> > regards, >> > >> > François >> > fpa...@apache.org >> > >> > Le 08/07/2019 à 18:15, michael.andre.pea...@me.com.INVALID a écrit : >> > > I think as a project we need to be clear in direction here with one >> > roadmap. To avoid users confusion. >> > > >> > > >> > > >> > > >> > > I was on the understanding that as a community and PMC a roadmap was >> > already agreed. >> > > >> > > >> > > >> > > >> > > And this was for artemis to become activemq 6 was agreed and once it >> has >> > all features (and more) of 5 which is now nearing. >> > > >> > > >> > > >> > > >> > > Its one of the reasons over the years features like jms 2 there hasnt >> > been effort to add it, as Artemis was the planned replacement that >> brought >> > jms 2 features amongst others. >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > Get Outlook for Android >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > On Tue, Jun 18, 2019 at 7:13 PM +0100, wrote: >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > Hi JB, >> > > >> > > I think it make a lot of sense to focus on this points and I will be >> > > more than happy to contribute! >> > > >> > > There is a very large community of users around the ActiveMQ 5.x and >> > > it's still very widely use in production environment. >> > > >> > > I'm not sure that the users actually understand the difference between >> > > ActiveMQ 5.x and Artemis, and why Artemis will became ActiveMQ 6.x. >> > > >> > > If ActiveMQ 5.x still has a long life, I think that the community >> should >> > > be clear about the 2 projects name. >> > > >> > > regards, >> > > >> > > François >> > > fpa...@apache.org >> > > >> > > Le 18/06/2019 à 19:44, Jean-Baptiste Onofré a écrit : >> > >> 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 >> > > >> > > >> > > >> > > >> > > >> > > >> > >> > >> > >> > >> > >> > >> > >> >> -- >> perl -e 'print >> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" );' >> >> ActiveMQ in Action: http://bit.ly/2je6cQ >> Blog: http://bsnyder.org/ <http://bruceblog.org/> >> Twitter: http://twitter.com/brucesnyder >> >
