As long as we can define a bigger scope.. otherwise wouldn't be an overkill to start a project for this?
What's the name? commons-messaging? but there's already a commons project within apache... I will be away for 2 weeks... Hope this to be sorted while I'm away .. .please??? Just kidding though.. if it's not sorted.. I may revisit this route as well. for now @michael use your or a new github account until we figure out where. On Thu, Jun 8, 2017 at 1:06 PM, Timothy Bish <[email protected]> wrote: > On 06/08/2017 11:21 AM, Michael André Pearce wrote: >> >> Hi All >> >> I would like to discuss proposing a new sub project , named >> "activemq-extras" >> >> There is some common / generic components not specific to activemq5 , >> artemis, qpid jms that currently live within or without some extras project >> would end up living in one. >> >> Some of these could be: >> PooledConnectionFactory >> Proposed custom serdes idea >> Possible future kafka integrations >> Etc. > > > Given the scope outlined here as well as the aspiration to make this a cross > cutting set of features that work with clients that aren't part of ActiveMQ > land but just JMS clients in general then I'd lean towards a -1 of creating > a new subproject or building new modules into Artemis that provide these > features. > > My suggestion would be to go the route of an incubator project where you > could work out the goals as aspirations of this new project and build a > community around that. I think there would be more willingness from folks > that aren't ActiveMQ centric developers to contribute to a project that > lives on it's own given the current goal seems to be that it's something > that works with many different JMS client implementations, most of which > aren't ActiveMQ.... > > Have a look at the incubator process (http://incubator.apache.org/) I think > it lends itself to what's being proposed here more so than just spinning up > a subproject and starting to write some code. > > > > >> The idea then is these "extras" are generic in fact they can be >> released independently, >> don't affect the core products >> are generic meaning they can be re-used. >> Optional for end users to use. >> >> Cheers >> Mike >> >> >> >> >> >> Sent from my iPhone > > > > -- > Tim Bish > twitter: @tabish121 > blog: http://timbish.blogspot.com/ > -- Clebert Suconic
