activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Bish <>
Subject Re: [DISCUSS] - Propose new sub-project activemq-extras
Date Fri, 09 Jun 2017 22:48:21 GMT
On 06/09/2017 09:58 AM, Matt Pavlovich wrote:
> Do we not already have precedent for something similar?  NMS is a sub-project of ActiveMQ
but includes support for non-ActiveMQ brokers.

The NMS bits aren't quite the same as this as the initial goal of that 
was to create a .NET based ActiveMQ client and it sort of morphed out 
from there.  There are some similarities though and in those you can 
kind of see the problem of putting a bunch of non-ActiveMQ type bits 
under and ActiveMQ subproject.  The NMS project has never grown much of 
a community of developers to support all the various client 
implementations, there's many just two people who contribute.  As such 
the project has mostly died, there hasn't been any releases in a long 
time, an some of the implementations have never seen an official release 
as there was nobody to manage it.  I felt for a long time like NMS would 
have been better served as it's own project but my desire to work on 
.NET code is quite low so I never pushed to move it to incubator but 
really that's what should have happened in my mind.

>> On Jun 9, 2017, at 8:39 AM, Timothy Bish <> wrote:
>> On 06/09/2017 09:04 AM, Clebert Suconic wrote:
>>> Yip. That's the idea.  The connection pool was mentioned at the top from
>>> Michael.
>>> I'm just thinking if we could expand the scope a bit so we won't open a new
>>> incubatorb project for just two libraries.
>> The initial scope as presented was
>> {quote}
>> Some of these could be:
>> PooledConnectionFactory
>> Proposed custom serdes idea
>> Possible future kafka integrations
>> Etc.
>> {quote}
>> Given you've got two concrete one sort of abstract and one etc it seems there's some
hints at there being more than just two libraries.  The thing I'd prefer not to do is to create
stuff that gets hidden in the noise of the ActiveMQ project which is to create a great messaging
broker where it could be something that can stand on its own and have its own community etc.
>> It seems that some actual thought about what you are trying to achieve with these
proposed bits will help sort out where they should live.  The natural thing to do is create
new ActiveMQ modules are subprojects but just because it's easy to do that doesn't always
mean its the best thing in the long run.
>>> Someone could argue that a messaging integration library should live on
>>> Camel as the Messaging Integration project.
>> Someone could argue that Camel already provides quite a bit of this....
>>> But I won't discuss much this now.  I'm about to travel and won't be able
>>> to answer emails next week.
>>> On Fri, Jun 9, 2017 at 5:34 AM Andy Taylor <> wrote:
>>>> The JMS connection Pool currently in ActiveMQ could live there
>>>> On 9 June 2017 at 04:52, Clebert Suconic <>
>>>> wrote:
>>>>> 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 <>
>>>> 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
>>>>> 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
>>>>> 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
>>>>>> community around that.  I think there would be more willingness from
>>>>> folks
>>>>>> that aren't ActiveMQ centric developers to contribute to a project
>>>>>> 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 (
>>>>> 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
>>>>>>> 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:
>>>>> --
>>>>> Clebert Suconic
>> -- 
>> Tim Bish
>> twitter: @tabish121
>> blog:

Tim Bish
twitter: @tabish121

View raw message