Like wise if say there some extended interface needed then it maybe the one to own it, eg some form of JMS extensions (like the bits proposed in JMS 2.1 ) that then the others could depend on.
Sent from my iPhone > On 8 Jun 2017, at 17:22, Michael André Pearce <[email protected]> > wrote: > > The idea of extras is they probably should only code to a spec (jms) or a > protocol level (amqp/mqtt) so it's generic / broker agnostic between > activemq5, artemis, qpid. > > As such the version of Artemis or ActiveMQ5 is irrelevant. Or at least > they're made to detect a version and auto toggle for feature compatibility > (in case of cli) > > and takes a CF so it's decoupled > > Sent from my iPhone > >> On 8 Jun 2017, at 17:08, Clebert Suconic <[email protected]> wrote: >> >> +1... >> >> The only thing is how we could release independently... then we could >> even move the CLI to this new project. >> >> >> >> >> On Thu, Jun 8, 2017 at 11:21 AM, Michael André Pearce >> <[email protected]> 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. >>> >>> 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 >> >> >> >> -- >> Clebert Suconic
