activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Shannon <christopher.l.shan...@gmail.com>
Subject Re: [DISCUSSION] ActiveMQ 5.x roadmap, codename ActiveMQ Missus
Date Thu, 11 Jul 2019 16:13:46 GMT
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 <bruce.snyder@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.pearce@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
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message