Do we not already have precedent for something similar?  NMS is a sub-project 
of ActiveMQ but includes support for non-ActiveMQ brokers. 

> On Jun 9, 2017, at 8:39 AM, Timothy Bish <[email protected]> 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 <[email protected]> wrote:
>> 
>>> The JMS connection Pool currently in ActiveMQ could live there
>>> 
>>> On 9 June 2017 at 04:52, Clebert Suconic <[email protected]>
>>> 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 <[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
>>>> 
> 
> -- 
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
> 

Reply via email to