You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by mi...@me.com.INVALID on 2019/07/08 16:15:33 UTC
Re: [DISCUSSION] ActiveMQ 5.x roadmap, codename ActiveMQ Missus
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, <fp...@apache.org> 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
fpapon@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
Re: [DISCUSSION] ActiveMQ 5.x roadmap, codename ActiveMQ Missus
Posted by Christopher Shannon <ch...@gmail.com>.
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.shannon@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 <br...@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 <mi...@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.papon@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
>> > fpapon@apache.org
>> >
>> > Le 08/07/2019 à 18:15, michael.andre.pearce@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
>> > > fpapon@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
>>
>
Re: [DISCUSSION] ActiveMQ 5.x roadmap, codename ActiveMQ Missus
Posted by Christopher Shannon <ch...@gmail.com>.
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.shannon@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 <br...@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 <mi...@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.papon@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
>> > fpapon@apache.org
>> >
>> > Le 08/07/2019 à 18:15, michael.andre.pearce@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
>> > > fpapon@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
>>
>
Re: [DISCUSSION] ActiveMQ 5.x roadmap, codename ActiveMQ Missus
Posted by Christopher Shannon <ch...@gmail.com>.
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 <br...@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 <mi...@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.papon@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
> > fpapon@apache.org
> >
> > Le 08/07/2019 à 18:15, michael.andre.pearce@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
> > > fpapon@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
>
Re: [DISCUSSION] ActiveMQ 5.x roadmap, codename ActiveMQ Missus
Posted by Clebert Suconic <cl...@gmail.com>.
>
> 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?
That’s still a goal. I am personally committed to that.
>
> Bruce
>
> On Thu, Jul 11, 2019 at 1:37 AM <mi...@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.papon@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
> > fpapon@apache.org
> >
> > Le 08/07/2019 à 18:15, michael.andre.pearce@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
> > > fpapon@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
>
--
Clebert Suconic
Re: [DISCUSSION] ActiveMQ 5.x roadmap, codename ActiveMQ Missus
Posted by Bruce Snyder <br...@gmail.com>.
(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 <mi...@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.papon@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
> fpapon@apache.org
>
> Le 08/07/2019 à 18:15, michael.andre.pearce@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
> > fpapon@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
Re: [DISCUSSION] ActiveMQ 5.x roadmap, codename ActiveMQ Missus
Posted by mi...@me.com.INVALID.
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" <fr...@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
fpapon@apache.org
Le 08/07/2019 à 18:15, michael.andre.pearce@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
> fpapon@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
>
>
>
>
>
>
Re: [DISCUSSION] ActiveMQ 5.x roadmap, codename ActiveMQ Missus
Posted by Francois Papon <fr...@openobject.fr>.
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
fpapon@apache.org
Le 08/07/2019 à 18:15, michael.andre.pearce@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, <fp...@apache.org> 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
> fpapon@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
>
>
>
>
>
>