You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Michael André Pearce <mi...@me.com> on 2017/06/08 15:21:42 UTC
[DISCUSS] - Propose new sub-project activemq-extras
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
Re: [DISCUSS] - Propose new sub-project activemq-extras
Posted by Michael André Pearce <mi...@me.com>.
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 <mi...@me.com> 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 <cl...@gmail.com> 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
>> <mi...@me.com> 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
Re: [DISCUSS] - Propose new sub-project activemq-extras
Posted by Michael André Pearce <mi...@me.com>.
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 <cl...@gmail.com> 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
> <mi...@me.com> 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
Re: [DISCUSS] - Propose new sub-project activemq-extras
Posted by Clebert Suconic <cl...@gmail.com>.
+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
<mi...@me.com> 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
Re: [DISCUSS] - Propose new sub-project activemq-extras
Posted by Michael André Pearce <mi...@me.com>.
Going to sound really lame I'm just signing my up to that list so don't have the mail thread to reply to it, any chance you could make some reply so then I can reply :)
Sent from my iPhone
> On 23 Jun 2017, at 16:18, Clebert Suconic <cl...@gmail.com> wrote:
>
> The discussion is moving to general at incubator.apache.org
>
> http://incubator.apache.org/guides/lists.html
>
> If other people is backing up this.. than I'm all up for it...
>
>
> so, if you support this, by that I mean.. if you want to get
> involved.. then it's a good time to show you interest on that thread:
>
> https://lists.apache.org/thread.html/14bdf3d93c8c6ac3ac7dd9c1d6e6146fd90991581d80e8c6cfaf9540@%3Cgeneral.incubator.apache.org%3E
>
>
>
>
>
> On Thu, Jun 22, 2017 at 12:46 PM, Clebert Suconic
> <cl...@gmail.com> wrote:
>> I think it will make sense a different project...
>>
>> for instance: if we make journal a pluggable component there, we could
>> have a JournalQueue and JournalHashMap to support some sort of client
>> side persistence..
>>
>> @John: you're the man here.. how we can get this rolling?
>>
>>> On Wed, Jun 21, 2017 at 2:31 PM, John D. Ament <jo...@apache.org> wrote:
>>> Plenty of commons projects use git... https://github.com/apache?q=commons
>>>
>>> John
>>>
>>> On Wed, Jun 21, 2017 at 2:27 PM Clebert Suconic <cl...@gmail.com>
>>> wrote:
>>>
>>>> One extra reason to not use commons:
>>>>
>>>>
>>>> SVN :)
>>>>
>>>>
>>>> How would we proceed? Since this is a new project I don't think we need a
>>>> vote here at activemq right?
>>>>
>>>> On Wed, Jun 21, 2017 at 2:19 PM Clebert Suconic <clebert.suconic@gmail.com
>>>>>
>>>> wrote:
>>>>
>>>>> On Wed, Jun 21, 2017 at 2:16 PM John D. Ament <jo...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> Well, in theory you could create an Apache Messaging Components project
>>>>>> that was made up a variety of small projects like this.
>>>>>>
>>>>>> For Kafka-JMS, I would strongly encourage you to work with the Kafka
>>>>>> Community to bring this to them first instead of creating a new project.
>>>>>
>>>>>
>>>>> Sure.
>>>>> That was just a rhetorical possibility. Didn't mean to list exact
>>>>> projects now. Just trying to determine in what direction this could go.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> John
>>>>>>
>>>>>> On Wed, Jun 21, 2017 at 2:12 PM Clebert Suconic <
>>>>>> clebert.suconic@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> There would be possibly a few smaller projects
>>>>>>>
>>>>>>>
>>>>>>> For now I can see at least 3.
>>>>>>>
>>>>>>> Pool
>>>>>>> Serialialization avro
>>>>>>> Kafka-JMS Integration.
>>>>>>>
>>>>>>>
>>>>>>> It would be beyond the scope of commons I think. Unless they are ok
>>>> with
>>>>>>> many small projects.
>>>>>>>
>>>>>>>
>>>>>>> In the past I wanted to spinof the journal and libaio separately also.
>>>>>>> Could we make this in this context of a new project ?
>>>>>>>
>>>>>>> Iif we made it something like messaging-tools these could all fit in
>>>> the
>>>>>>> same sub project?.
>>>>>>>
>>>>>>> On Wed, Jun 21, 2017 at 1:52 PM John D. Ament <jo...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> We can definitely try an incubating project, if it makes sense for
>>>>>> this
>>>>>>> to
>>>>>>>> be an eventual TLP or subproject. However, I was wondering if
>>>> Apache
>>>>>>>> Commons was a possible location for this project? They tend to run
>>>>>> with
>>>>>>> ad
>>>>>>>> hoc smallish projects with a single PMC with enough oversight to cut
>>>>>>> valid
>>>>>>>> releases. Their projects are generally smaller, utility libraries
>>>> and
>>>>>>> the
>>>>>>>> core inners of projects.
>>>>>>>>
>>>>>>>> Let me know if you want to proceed with incubation. We'd need to
>>>> dig
>>>>>> up
>>>>>>>> some mentors for the project.
>>>>>>>>
>>>>>>>> John
>>>>>>>>
>>>>>>>> On Fri, Jun 9, 2017 at 6:48 PM Timothy Bish <ta...@gmail.com>
>>>>>> wrote:
>>>>>>>>
>>>>>>>>>> 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 <ta...@gmail.com>
>>>>>>> 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 <
>>>>>> andy.tayls67@gmail.com
>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> The JMS connection Pool currently in ActiveMQ could live
>>>> there
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 9 June 2017 at 04:52, Clebert Suconic <
>>>>>>> clebert.suconic@gmail.com
>>>>>>>>>
>>>>>>>>>>>>> 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 <
>>>>>>> tabish121@gmail.com>
>>>>>>>>>>>>> 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/
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Tim Bish
>>>>>>>>> twitter: @tabish121
>>>>>>>>> blog: http://timbish.blogspot.com/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> Clebert Suconic
>>>>>>>
>>>>>>
>>>>> --
>>>>> Clebert Suconic
>>>>>
>>>> --
>>>> Clebert Suconic
>>>>
>>
>>
>>
>> --
>> Clebert Suconic
>
>
>
> --
> Clebert Suconic
Re: [DISCUSS] - Propose new sub-project activemq-extras
Posted by Clebert Suconic <cl...@gmail.com>.
The discussion is moving to general at incubator.apache.org
http://incubator.apache.org/guides/lists.html
If other people is backing up this.. than I'm all up for it...
so, if you support this, by that I mean.. if you want to get
involved.. then it's a good time to show you interest on that thread:
https://lists.apache.org/thread.html/14bdf3d93c8c6ac3ac7dd9c1d6e6146fd90991581d80e8c6cfaf9540@%3Cgeneral.incubator.apache.org%3E
On Thu, Jun 22, 2017 at 12:46 PM, Clebert Suconic
<cl...@gmail.com> wrote:
> I think it will make sense a different project...
>
> for instance: if we make journal a pluggable component there, we could
> have a JournalQueue and JournalHashMap to support some sort of client
> side persistence..
>
> @John: you're the man here.. how we can get this rolling?
>
> On Wed, Jun 21, 2017 at 2:31 PM, John D. Ament <jo...@apache.org> wrote:
>> Plenty of commons projects use git... https://github.com/apache?q=commons
>>
>> John
>>
>> On Wed, Jun 21, 2017 at 2:27 PM Clebert Suconic <cl...@gmail.com>
>> wrote:
>>
>>> One extra reason to not use commons:
>>>
>>>
>>> SVN :)
>>>
>>>
>>> How would we proceed? Since this is a new project I don't think we need a
>>> vote here at activemq right?
>>>
>>> On Wed, Jun 21, 2017 at 2:19 PM Clebert Suconic <clebert.suconic@gmail.com
>>> >
>>> wrote:
>>>
>>> > On Wed, Jun 21, 2017 at 2:16 PM John D. Ament <jo...@apache.org>
>>> > wrote:
>>> >
>>> >> Well, in theory you could create an Apache Messaging Components project
>>> >> that was made up a variety of small projects like this.
>>> >>
>>> >> For Kafka-JMS, I would strongly encourage you to work with the Kafka
>>> >> Community to bring this to them first instead of creating a new project.
>>> >
>>> >
>>> > Sure.
>>> > That was just a rhetorical possibility. Didn't mean to list exact
>>> > projects now. Just trying to determine in what direction this could go.
>>> >
>>> >
>>> >
>>> >>
>>> >> John
>>> >>
>>> >> On Wed, Jun 21, 2017 at 2:12 PM Clebert Suconic <
>>> >> clebert.suconic@gmail.com>
>>> >> wrote:
>>> >>
>>> >> > There would be possibly a few smaller projects
>>> >> >
>>> >> >
>>> >> > For now I can see at least 3.
>>> >> >
>>> >> > Pool
>>> >> > Serialialization avro
>>> >> > Kafka-JMS Integration.
>>> >> >
>>> >> >
>>> >> > It would be beyond the scope of commons I think. Unless they are ok
>>> with
>>> >> > many small projects.
>>> >> >
>>> >> >
>>> >> > In the past I wanted to spinof the journal and libaio separately also.
>>> >> > Could we make this in this context of a new project ?
>>> >> >
>>> >> > Iif we made it something like messaging-tools these could all fit in
>>> the
>>> >> > same sub project?.
>>> >> >
>>> >> > On Wed, Jun 21, 2017 at 1:52 PM John D. Ament <jo...@apache.org>
>>> >> > wrote:
>>> >> >
>>> >> > > We can definitely try an incubating project, if it makes sense for
>>> >> this
>>> >> > to
>>> >> > > be an eventual TLP or subproject. However, I was wondering if
>>> Apache
>>> >> > > Commons was a possible location for this project? They tend to run
>>> >> with
>>> >> > ad
>>> >> > > hoc smallish projects with a single PMC with enough oversight to cut
>>> >> > valid
>>> >> > > releases. Their projects are generally smaller, utility libraries
>>> and
>>> >> > the
>>> >> > > core inners of projects.
>>> >> > >
>>> >> > > Let me know if you want to proceed with incubation. We'd need to
>>> dig
>>> >> up
>>> >> > > some mentors for the project.
>>> >> > >
>>> >> > > John
>>> >> > >
>>> >> > > On Fri, Jun 9, 2017 at 6:48 PM Timothy Bish <ta...@gmail.com>
>>> >> wrote:
>>> >> > >
>>> >> > > > 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 <ta...@gmail.com>
>>> >> > 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 <
>>> >> andy.tayls67@gmail.com
>>> >> > >
>>> >> > > > wrote:
>>> >> > > > >>>
>>> >> > > > >>>> The JMS connection Pool currently in ActiveMQ could live
>>> there
>>> >> > > > >>>>
>>> >> > > > >>>> On 9 June 2017 at 04:52, Clebert Suconic <
>>> >> > clebert.suconic@gmail.com
>>> >> > > >
>>> >> > > > >>>> 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 <
>>> >> > tabish121@gmail.com>
>>> >> > > > >>>> 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/
>>> >> > > > >>
>>> >> > > > >
>>> >> > > >
>>> >> > > > --
>>> >> > > > Tim Bish
>>> >> > > > twitter: @tabish121
>>> >> > > > blog: http://timbish.blogspot.com/
>>> >> > > >
>>> >> > > >
>>> >> > >
>>> >> > --
>>> >> > Clebert Suconic
>>> >> >
>>> >>
>>> > --
>>> > Clebert Suconic
>>> >
>>> --
>>> Clebert Suconic
>>>
>
>
>
> --
> Clebert Suconic
--
Clebert Suconic
Re: [DISCUSS] - Propose new sub-project activemq-extras
Posted by Clebert Suconic <cl...@gmail.com>.
I think it will make sense a different project...
for instance: if we make journal a pluggable component there, we could
have a JournalQueue and JournalHashMap to support some sort of client
side persistence..
@John: you're the man here.. how we can get this rolling?
On Wed, Jun 21, 2017 at 2:31 PM, John D. Ament <jo...@apache.org> wrote:
> Plenty of commons projects use git... https://github.com/apache?q=commons
>
> John
>
> On Wed, Jun 21, 2017 at 2:27 PM Clebert Suconic <cl...@gmail.com>
> wrote:
>
>> One extra reason to not use commons:
>>
>>
>> SVN :)
>>
>>
>> How would we proceed? Since this is a new project I don't think we need a
>> vote here at activemq right?
>>
>> On Wed, Jun 21, 2017 at 2:19 PM Clebert Suconic <clebert.suconic@gmail.com
>> >
>> wrote:
>>
>> > On Wed, Jun 21, 2017 at 2:16 PM John D. Ament <jo...@apache.org>
>> > wrote:
>> >
>> >> Well, in theory you could create an Apache Messaging Components project
>> >> that was made up a variety of small projects like this.
>> >>
>> >> For Kafka-JMS, I would strongly encourage you to work with the Kafka
>> >> Community to bring this to them first instead of creating a new project.
>> >
>> >
>> > Sure.
>> > That was just a rhetorical possibility. Didn't mean to list exact
>> > projects now. Just trying to determine in what direction this could go.
>> >
>> >
>> >
>> >>
>> >> John
>> >>
>> >> On Wed, Jun 21, 2017 at 2:12 PM Clebert Suconic <
>> >> clebert.suconic@gmail.com>
>> >> wrote:
>> >>
>> >> > There would be possibly a few smaller projects
>> >> >
>> >> >
>> >> > For now I can see at least 3.
>> >> >
>> >> > Pool
>> >> > Serialialization avro
>> >> > Kafka-JMS Integration.
>> >> >
>> >> >
>> >> > It would be beyond the scope of commons I think. Unless they are ok
>> with
>> >> > many small projects.
>> >> >
>> >> >
>> >> > In the past I wanted to spinof the journal and libaio separately also.
>> >> > Could we make this in this context of a new project ?
>> >> >
>> >> > Iif we made it something like messaging-tools these could all fit in
>> the
>> >> > same sub project?.
>> >> >
>> >> > On Wed, Jun 21, 2017 at 1:52 PM John D. Ament <jo...@apache.org>
>> >> > wrote:
>> >> >
>> >> > > We can definitely try an incubating project, if it makes sense for
>> >> this
>> >> > to
>> >> > > be an eventual TLP or subproject. However, I was wondering if
>> Apache
>> >> > > Commons was a possible location for this project? They tend to run
>> >> with
>> >> > ad
>> >> > > hoc smallish projects with a single PMC with enough oversight to cut
>> >> > valid
>> >> > > releases. Their projects are generally smaller, utility libraries
>> and
>> >> > the
>> >> > > core inners of projects.
>> >> > >
>> >> > > Let me know if you want to proceed with incubation. We'd need to
>> dig
>> >> up
>> >> > > some mentors for the project.
>> >> > >
>> >> > > John
>> >> > >
>> >> > > On Fri, Jun 9, 2017 at 6:48 PM Timothy Bish <ta...@gmail.com>
>> >> wrote:
>> >> > >
>> >> > > > 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 <ta...@gmail.com>
>> >> > 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 <
>> >> andy.tayls67@gmail.com
>> >> > >
>> >> > > > wrote:
>> >> > > > >>>
>> >> > > > >>>> The JMS connection Pool currently in ActiveMQ could live
>> there
>> >> > > > >>>>
>> >> > > > >>>> On 9 June 2017 at 04:52, Clebert Suconic <
>> >> > clebert.suconic@gmail.com
>> >> > > >
>> >> > > > >>>> 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 <
>> >> > tabish121@gmail.com>
>> >> > > > >>>> 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/
>> >> > > > >>
>> >> > > > >
>> >> > > >
>> >> > > > --
>> >> > > > Tim Bish
>> >> > > > twitter: @tabish121
>> >> > > > blog: http://timbish.blogspot.com/
>> >> > > >
>> >> > > >
>> >> > >
>> >> > --
>> >> > Clebert Suconic
>> >> >
>> >>
>> > --
>> > Clebert Suconic
>> >
>> --
>> Clebert Suconic
>>
--
Clebert Suconic
Re: [DISCUSS] - Propose new sub-project activemq-extras
Posted by "John D. Ament" <jo...@apache.org>.
Plenty of commons projects use git... https://github.com/apache?q=commons
John
On Wed, Jun 21, 2017 at 2:27 PM Clebert Suconic <cl...@gmail.com>
wrote:
> One extra reason to not use commons:
>
>
> SVN :)
>
>
> How would we proceed? Since this is a new project I don't think we need a
> vote here at activemq right?
>
> On Wed, Jun 21, 2017 at 2:19 PM Clebert Suconic <clebert.suconic@gmail.com
> >
> wrote:
>
> > On Wed, Jun 21, 2017 at 2:16 PM John D. Ament <jo...@apache.org>
> > wrote:
> >
> >> Well, in theory you could create an Apache Messaging Components project
> >> that was made up a variety of small projects like this.
> >>
> >> For Kafka-JMS, I would strongly encourage you to work with the Kafka
> >> Community to bring this to them first instead of creating a new project.
> >
> >
> > Sure.
> > That was just a rhetorical possibility. Didn't mean to list exact
> > projects now. Just trying to determine in what direction this could go.
> >
> >
> >
> >>
> >> John
> >>
> >> On Wed, Jun 21, 2017 at 2:12 PM Clebert Suconic <
> >> clebert.suconic@gmail.com>
> >> wrote:
> >>
> >> > There would be possibly a few smaller projects
> >> >
> >> >
> >> > For now I can see at least 3.
> >> >
> >> > Pool
> >> > Serialialization avro
> >> > Kafka-JMS Integration.
> >> >
> >> >
> >> > It would be beyond the scope of commons I think. Unless they are ok
> with
> >> > many small projects.
> >> >
> >> >
> >> > In the past I wanted to spinof the journal and libaio separately also.
> >> > Could we make this in this context of a new project ?
> >> >
> >> > Iif we made it something like messaging-tools these could all fit in
> the
> >> > same sub project?.
> >> >
> >> > On Wed, Jun 21, 2017 at 1:52 PM John D. Ament <jo...@apache.org>
> >> > wrote:
> >> >
> >> > > We can definitely try an incubating project, if it makes sense for
> >> this
> >> > to
> >> > > be an eventual TLP or subproject. However, I was wondering if
> Apache
> >> > > Commons was a possible location for this project? They tend to run
> >> with
> >> > ad
> >> > > hoc smallish projects with a single PMC with enough oversight to cut
> >> > valid
> >> > > releases. Their projects are generally smaller, utility libraries
> and
> >> > the
> >> > > core inners of projects.
> >> > >
> >> > > Let me know if you want to proceed with incubation. We'd need to
> dig
> >> up
> >> > > some mentors for the project.
> >> > >
> >> > > John
> >> > >
> >> > > On Fri, Jun 9, 2017 at 6:48 PM Timothy Bish <ta...@gmail.com>
> >> wrote:
> >> > >
> >> > > > 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 <ta...@gmail.com>
> >> > 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 <
> >> andy.tayls67@gmail.com
> >> > >
> >> > > > wrote:
> >> > > > >>>
> >> > > > >>>> The JMS connection Pool currently in ActiveMQ could live
> there
> >> > > > >>>>
> >> > > > >>>> On 9 June 2017 at 04:52, Clebert Suconic <
> >> > clebert.suconic@gmail.com
> >> > > >
> >> > > > >>>> 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 <
> >> > tabish121@gmail.com>
> >> > > > >>>> 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/
> >> > > > >>
> >> > > > >
> >> > > >
> >> > > > --
> >> > > > Tim Bish
> >> > > > twitter: @tabish121
> >> > > > blog: http://timbish.blogspot.com/
> >> > > >
> >> > > >
> >> > >
> >> > --
> >> > Clebert Suconic
> >> >
> >>
> > --
> > Clebert Suconic
> >
> --
> Clebert Suconic
>
Re: [DISCUSS] - Propose new sub-project activemq-extras
Posted by Clebert Suconic <cl...@gmail.com>.
One extra reason to not use commons:
SVN :)
How would we proceed? Since this is a new project I don't think we need a
vote here at activemq right?
On Wed, Jun 21, 2017 at 2:19 PM Clebert Suconic <cl...@gmail.com>
wrote:
> On Wed, Jun 21, 2017 at 2:16 PM John D. Ament <jo...@apache.org>
> wrote:
>
>> Well, in theory you could create an Apache Messaging Components project
>> that was made up a variety of small projects like this.
>>
>> For Kafka-JMS, I would strongly encourage you to work with the Kafka
>> Community to bring this to them first instead of creating a new project.
>
>
> Sure.
> That was just a rhetorical possibility. Didn't mean to list exact
> projects now. Just trying to determine in what direction this could go.
>
>
>
>>
>> John
>>
>> On Wed, Jun 21, 2017 at 2:12 PM Clebert Suconic <
>> clebert.suconic@gmail.com>
>> wrote:
>>
>> > There would be possibly a few smaller projects
>> >
>> >
>> > For now I can see at least 3.
>> >
>> > Pool
>> > Serialialization avro
>> > Kafka-JMS Integration.
>> >
>> >
>> > It would be beyond the scope of commons I think. Unless they are ok with
>> > many small projects.
>> >
>> >
>> > In the past I wanted to spinof the journal and libaio separately also.
>> > Could we make this in this context of a new project ?
>> >
>> > Iif we made it something like messaging-tools these could all fit in the
>> > same sub project?.
>> >
>> > On Wed, Jun 21, 2017 at 1:52 PM John D. Ament <jo...@apache.org>
>> > wrote:
>> >
>> > > We can definitely try an incubating project, if it makes sense for
>> this
>> > to
>> > > be an eventual TLP or subproject. However, I was wondering if Apache
>> > > Commons was a possible location for this project? They tend to run
>> with
>> > ad
>> > > hoc smallish projects with a single PMC with enough oversight to cut
>> > valid
>> > > releases. Their projects are generally smaller, utility libraries and
>> > the
>> > > core inners of projects.
>> > >
>> > > Let me know if you want to proceed with incubation. We'd need to dig
>> up
>> > > some mentors for the project.
>> > >
>> > > John
>> > >
>> > > On Fri, Jun 9, 2017 at 6:48 PM Timothy Bish <ta...@gmail.com>
>> wrote:
>> > >
>> > > > 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 <ta...@gmail.com>
>> > 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 <
>> andy.tayls67@gmail.com
>> > >
>> > > > wrote:
>> > > > >>>
>> > > > >>>> The JMS connection Pool currently in ActiveMQ could live there
>> > > > >>>>
>> > > > >>>> On 9 June 2017 at 04:52, Clebert Suconic <
>> > clebert.suconic@gmail.com
>> > > >
>> > > > >>>> 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 <
>> > tabish121@gmail.com>
>> > > > >>>> 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/
>> > > > >>
>> > > > >
>> > > >
>> > > > --
>> > > > Tim Bish
>> > > > twitter: @tabish121
>> > > > blog: http://timbish.blogspot.com/
>> > > >
>> > > >
>> > >
>> > --
>> > Clebert Suconic
>> >
>>
> --
> Clebert Suconic
>
--
Clebert Suconic
Re: [DISCUSS] - Propose new sub-project activemq-extras
Posted by Clebert Suconic <cl...@gmail.com>.
On Wed, Jun 21, 2017 at 2:16 PM John D. Ament <jo...@apache.org> wrote:
> Well, in theory you could create an Apache Messaging Components project
> that was made up a variety of small projects like this.
>
> For Kafka-JMS, I would strongly encourage you to work with the Kafka
> Community to bring this to them first instead of creating a new project.
Sure.
That was just a rhetorical possibility. Didn't mean to list exact projects
now. Just trying to determine in what direction this could go.
>
> John
>
> On Wed, Jun 21, 2017 at 2:12 PM Clebert Suconic <clebert.suconic@gmail.com
> >
> wrote:
>
> > There would be possibly a few smaller projects
> >
> >
> > For now I can see at least 3.
> >
> > Pool
> > Serialialization avro
> > Kafka-JMS Integration.
> >
> >
> > It would be beyond the scope of commons I think. Unless they are ok with
> > many small projects.
> >
> >
> > In the past I wanted to spinof the journal and libaio separately also.
> > Could we make this in this context of a new project ?
> >
> > Iif we made it something like messaging-tools these could all fit in the
> > same sub project?.
> >
> > On Wed, Jun 21, 2017 at 1:52 PM John D. Ament <jo...@apache.org>
> > wrote:
> >
> > > We can definitely try an incubating project, if it makes sense for this
> > to
> > > be an eventual TLP or subproject. However, I was wondering if Apache
> > > Commons was a possible location for this project? They tend to run
> with
> > ad
> > > hoc smallish projects with a single PMC with enough oversight to cut
> > valid
> > > releases. Their projects are generally smaller, utility libraries and
> > the
> > > core inners of projects.
> > >
> > > Let me know if you want to proceed with incubation. We'd need to dig
> up
> > > some mentors for the project.
> > >
> > > John
> > >
> > > On Fri, Jun 9, 2017 at 6:48 PM Timothy Bish <ta...@gmail.com>
> wrote:
> > >
> > > > 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 <ta...@gmail.com>
> > 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 <
> andy.tayls67@gmail.com
> > >
> > > > wrote:
> > > > >>>
> > > > >>>> The JMS connection Pool currently in ActiveMQ could live there
> > > > >>>>
> > > > >>>> On 9 June 2017 at 04:52, Clebert Suconic <
> > clebert.suconic@gmail.com
> > > >
> > > > >>>> 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 <
> > tabish121@gmail.com>
> > > > >>>> 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/
> > > > >>
> > > > >
> > > >
> > > > --
> > > > Tim Bish
> > > > twitter: @tabish121
> > > > blog: http://timbish.blogspot.com/
> > > >
> > > >
> > >
> > --
> > Clebert Suconic
> >
>
--
Clebert Suconic
Re: [DISCUSS] - Propose new sub-project activemq-extras
Posted by "John D. Ament" <jo...@apache.org>.
Well, in theory you could create an Apache Messaging Components project
that was made up a variety of small projects like this.
For Kafka-JMS, I would strongly encourage you to work with the Kafka
Community to bring this to them first instead of creating a new project.
John
On Wed, Jun 21, 2017 at 2:12 PM Clebert Suconic <cl...@gmail.com>
wrote:
> There would be possibly a few smaller projects
>
>
> For now I can see at least 3.
>
> Pool
> Serialialization avro
> Kafka-JMS Integration.
>
>
> It would be beyond the scope of commons I think. Unless they are ok with
> many small projects.
>
>
> In the past I wanted to spinof the journal and libaio separately also.
> Could we make this in this context of a new project ?
>
> Iif we made it something like messaging-tools these could all fit in the
> same sub project?.
>
> On Wed, Jun 21, 2017 at 1:52 PM John D. Ament <jo...@apache.org>
> wrote:
>
> > We can definitely try an incubating project, if it makes sense for this
> to
> > be an eventual TLP or subproject. However, I was wondering if Apache
> > Commons was a possible location for this project? They tend to run with
> ad
> > hoc smallish projects with a single PMC with enough oversight to cut
> valid
> > releases. Their projects are generally smaller, utility libraries and
> the
> > core inners of projects.
> >
> > Let me know if you want to proceed with incubation. We'd need to dig up
> > some mentors for the project.
> >
> > John
> >
> > On Fri, Jun 9, 2017 at 6:48 PM Timothy Bish <ta...@gmail.com> wrote:
> >
> > > 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 <ta...@gmail.com>
> 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 <andy.tayls67@gmail.com
> >
> > > wrote:
> > > >>>
> > > >>>> The JMS connection Pool currently in ActiveMQ could live there
> > > >>>>
> > > >>>> On 9 June 2017 at 04:52, Clebert Suconic <
> clebert.suconic@gmail.com
> > >
> > > >>>> 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 <
> tabish121@gmail.com>
> > > >>>> 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/
> > > >>
> > > >
> > >
> > > --
> > > Tim Bish
> > > twitter: @tabish121
> > > blog: http://timbish.blogspot.com/
> > >
> > >
> >
> --
> Clebert Suconic
>
Re: [DISCUSS] - Propose new sub-project activemq-extras
Posted by Clebert Suconic <cl...@gmail.com>.
There would be possibly a few smaller projects
For now I can see at least 3.
Pool
Serialialization avro
Kafka-JMS Integration.
It would be beyond the scope of commons I think. Unless they are ok with
many small projects.
In the past I wanted to spinof the journal and libaio separately also.
Could we make this in this context of a new project ?
Iif we made it something like messaging-tools these could all fit in the
same sub project?.
On Wed, Jun 21, 2017 at 1:52 PM John D. Ament <jo...@apache.org> wrote:
> We can definitely try an incubating project, if it makes sense for this to
> be an eventual TLP or subproject. However, I was wondering if Apache
> Commons was a possible location for this project? They tend to run with ad
> hoc smallish projects with a single PMC with enough oversight to cut valid
> releases. Their projects are generally smaller, utility libraries and the
> core inners of projects.
>
> Let me know if you want to proceed with incubation. We'd need to dig up
> some mentors for the project.
>
> John
>
> On Fri, Jun 9, 2017 at 6:48 PM Timothy Bish <ta...@gmail.com> wrote:
>
> > 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 <ta...@gmail.com> 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 <an...@gmail.com>
> > wrote:
> > >>>
> > >>>> The JMS connection Pool currently in ActiveMQ could live there
> > >>>>
> > >>>> On 9 June 2017 at 04:52, Clebert Suconic <clebert.suconic@gmail.com
> >
> > >>>> 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 <ta...@gmail.com>
> > >>>> 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/
> > >>
> > >
> >
> > --
> > Tim Bish
> > twitter: @tabish121
> > blog: http://timbish.blogspot.com/
> >
> >
>
--
Clebert Suconic
Re: [DISCUSS] - Propose new sub-project activemq-extras
Posted by "John D. Ament" <jo...@apache.org>.
We can definitely try an incubating project, if it makes sense for this to
be an eventual TLP or subproject. However, I was wondering if Apache
Commons was a possible location for this project? They tend to run with ad
hoc smallish projects with a single PMC with enough oversight to cut valid
releases. Their projects are generally smaller, utility libraries and the
core inners of projects.
Let me know if you want to proceed with incubation. We'd need to dig up
some mentors for the project.
John
On Fri, Jun 9, 2017 at 6:48 PM Timothy Bish <ta...@gmail.com> wrote:
> 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 <ta...@gmail.com> 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 <an...@gmail.com>
> wrote:
> >>>
> >>>> The JMS connection Pool currently in ActiveMQ could live there
> >>>>
> >>>> On 9 June 2017 at 04:52, Clebert Suconic <cl...@gmail.com>
> >>>> 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 <ta...@gmail.com>
> >>>> 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/
> >>
> >
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>
Re: [DISCUSS] - Propose new sub-project activemq-extras
Posted by Timothy Bish <ta...@gmail.com>.
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 <ta...@gmail.com> 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 <an...@gmail.com> wrote:
>>>
>>>> The JMS connection Pool currently in ActiveMQ could live there
>>>>
>>>> On 9 June 2017 at 04:52, Clebert Suconic <cl...@gmail.com>
>>>> 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 <ta...@gmail.com>
>>>> 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/
>>
>
--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/
Re: [DISCUSS] - Propose new sub-project activemq-extras
Posted by Matt Pavlovich <ma...@gmail.com>.
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 <ta...@gmail.com> 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 <an...@gmail.com> wrote:
>>
>>> The JMS connection Pool currently in ActiveMQ could live there
>>>
>>> On 9 June 2017 at 04:52, Clebert Suconic <cl...@gmail.com>
>>> 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 <ta...@gmail.com>
>>> 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/
>
Re: [DISCUSS] - Propose new sub-project activemq-extras
Posted by Clebert Suconic <cl...@gmail.com>.
>>
>> 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....
>
That's a good argument to expand Camel actually. I don't want to drive
a decision now.. as I said I'm not on the mood to work .... vacations!
:)
Re: [DISCUSS] - Propose new sub-project activemq-extras
Posted by Timothy Bish <ta...@gmail.com>.
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 <an...@gmail.com> wrote:
>
>> The JMS connection Pool currently in ActiveMQ could live there
>>
>> On 9 June 2017 at 04:52, Clebert Suconic <cl...@gmail.com>
>> 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 <ta...@gmail.com>
>> 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/
Re: [DISCUSS] - Propose new sub-project activemq-extras
Posted by Clebert Suconic <cl...@gmail.com>.
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.
Someone could argue that a messaging integration library should live on
Camel as the Messaging Integration project.
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 <an...@gmail.com> wrote:
> The JMS connection Pool currently in ActiveMQ could live there
>
> On 9 June 2017 at 04:52, Clebert Suconic <cl...@gmail.com>
> 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 <ta...@gmail.com>
> 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
> >
>
--
Clebert Suconic
Re: [DISCUSS] - Propose new sub-project activemq-extras
Posted by Andy Taylor <an...@gmail.com>.
The JMS connection Pool currently in ActiveMQ could live there
On 9 June 2017 at 04:52, Clebert Suconic <cl...@gmail.com> 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 <ta...@gmail.com> 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
>
Re: [DISCUSS] - Propose new sub-project activemq-extras
Posted by Clebert Suconic <cl...@gmail.com>.
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 <ta...@gmail.com> 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
Re: [DISCUSS] - Propose new sub-project activemq-extras
Posted by Timothy Bish <ta...@gmail.com>.
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/