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 <[email protected]> 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 > <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>> 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 <[email protected] >>>>> >>>> wrote: >>>> >>>>> On Wed, Jun 21, 2017 at 2:16 PM John D. Ament <[email protected]> >>>>> 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 < >>>>>> [email protected]> >>>>>> 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 <[email protected]> >>>>>>> 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 <[email protected]> >>>>>> 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 <[email protected]> >>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> On 06/09/2017 09:04 AM, Clebert Suconic wrote: >>>>>>>>>>>> Yip. That's the idea. The connection pool was mentioned at >>>> the >>>>>> top >>>>>>>>> from >>>>>>>>>>>> Michael. >>>>>>>>>>>> >>>>>>>>>>>> I'm just thinking if we could expand the scope a bit so we >>>> won't >>>>>>> open >>>>>>>>> a new >>>>>>>>>>>> incubatorb project for just two libraries. >>>>>>>>>>> The initial scope as presented was >>>>>>>>>>> >>>>>>>>>>> {quote} >>>>>>>>>>> Some of these could be: >>>>>>>>>>> PooledConnectionFactory >>>>>>>>>>> Proposed custom serdes idea >>>>>>>>>>> Possible future kafka integrations >>>>>>>>>>> Etc. >>>>>>>>>>> {quote} >>>>>>>>>>> >>>>>>>>>>> Given you've got two concrete one sort of abstract and one etc >>>> it >>>>>>>> seems >>>>>>>>> there's some hints at there being more than just two libraries. >>>> The >>>>>>>> thing >>>>>>>>> I'd prefer not to do is to create stuff that gets hidden in the >>>>>> noise >>>>>>> of >>>>>>>>> the ActiveMQ project which is to create a great messaging broker >>>>>> where >>>>>>> it >>>>>>>>> could be something that can stand on its own and have its own >>>>>> community >>>>>>>> etc. >>>>>>>>>>> >>>>>>>>>>> It seems that some actual thought about what you are trying to >>>>>>> achieve >>>>>>>>> with these proposed bits will help sort out where they should >>>> live. >>>>>>> The >>>>>>>>> natural thing to do is create new ActiveMQ modules are subprojects >>>>>> but >>>>>>>> just >>>>>>>>> because it's easy to do that doesn't always mean its the best >>>> thing >>>>>> in >>>>>>>> the >>>>>>>>> long run. >>>>>>>>>>> >>>>>>>>>>>> Someone could argue that a messaging integration library >>>> should >>>>>>> live >>>>>>>> on >>>>>>>>>>>> Camel as the Messaging Integration project. >>>>>>>>>>> Someone could argue that Camel already provides quite a bit of >>>>>>>> this.... >>>>>>>>>>> >>>>>>>>>>>> But I won't discuss much this now. I'm about to travel and >>>>>> won't >>>>>>> be >>>>>>>>> able >>>>>>>>>>>> to answer emails next week. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Jun 9, 2017 at 5:34 AM Andy Taylor < >>>>>> [email protected] >>>>>>>> >>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> The JMS connection Pool currently in ActiveMQ could live >>>> there >>>>>>>>>>>>> >>>>>>>>>>>>> On 9 June 2017 at 04:52, Clebert Suconic < >>>>>>> [email protected] >>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> As long as we can define a bigger scope.. otherwise wouldn't >>>>>> be >>>>>>> an >>>>>>>>>>>>>> overkill to start a project for this? >>>>>>>>>>>>>> >>>>>>>>>>>>>> What's the name? commons-messaging? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> but there's already a commons project within apache... >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I will be away for 2 weeks... Hope this to be sorted while >>>> I'm >>>>>>> away >>>>>>>>> .. >>>>>>>>>>>>>> .please??? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Just kidding though.. if it's not sorted.. I may revisit >>>> this >>>>>>> route >>>>>>>>> as >>>>>>>>>>>>>> well. for now @michael use your or a new github account >>>> until >>>>>> we >>>>>>>>>>>>>> figure out where. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Jun 8, 2017 at 1:06 PM, Timothy Bish < >>>>>>> [email protected]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> On 06/08/2017 11:21 AM, Michael André Pearce wrote: >>>>>>>>>>>>>>>> Hi All >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I would like to discuss proposing a new sub project , >>>> named >>>>>>>>>>>>>>>> "activemq-extras" >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There is some common / generic components not specific to >>>>>>>>> activemq5 , >>>>>>>>>>>>>>>> artemis, qpid jms that currently live within or without >>>> some >>>>>>>> extras >>>>>>>>>>>>>> project >>>>>>>>>>>>>>>> would end up living in one. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Some of these could be: >>>>>>>>>>>>>>>> PooledConnectionFactory >>>>>>>>>>>>>>>> Proposed custom serdes idea >>>>>>>>>>>>>>>> Possible future kafka integrations >>>>>>>>>>>>>>>> Etc. >>>>>>>>>>>>>>> Given the scope outlined here as well as the aspiration to >>>>>> make >>>>>>>>> this a >>>>>>>>>>>>>> cross >>>>>>>>>>>>>>> cutting set of features that work with clients that aren't >>>>>> part >>>>>>> of >>>>>>>>>>>>>> ActiveMQ >>>>>>>>>>>>>>> land but just JMS clients in general then I'd lean towards >>>> a >>>>>> -1 >>>>>>> of >>>>>>>>>>>>>> creating >>>>>>>>>>>>>>> a new subproject or building new modules into Artemis that >>>>>>> provide >>>>>>>>>>>>> these >>>>>>>>>>>>>>> features. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> My suggestion would be to go the route of an incubator >>>>>> project >>>>>>>> where >>>>>>>>>>>>> you >>>>>>>>>>>>>>> could work out the goals as aspirations of this new project >>>>>> and >>>>>>>>> build a >>>>>>>>>>>>>>> community around that. I think there would be more >>>>>> willingness >>>>>>>> from >>>>>>>>>>>>>> folks >>>>>>>>>>>>>>> that aren't ActiveMQ centric developers to contribute to a >>>>>>> project >>>>>>>>> that >>>>>>>>>>>>>>> lives on it's own given the current goal seems to be that >>>>>> it's >>>>>>>>>>>>> something >>>>>>>>>>>>>>> that works with many different JMS client implementations, >>>>>> most >>>>>>> of >>>>>>>>>>>>> which >>>>>>>>>>>>>>> aren't ActiveMQ.... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Have a look at the incubator process ( >>>>>>>> http://incubator.apache.org/) >>>>>>>>> I >>>>>>>>>>>>>> think >>>>>>>>>>>>>>> it lends itself to what's being proposed here more so than >>>>>> just >>>>>>>>>>>>> spinning >>>>>>>>>>>>>> up >>>>>>>>>>>>>>> a subproject and starting to write some code. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The idea then is these "extras" are generic in fact they >>>>>> can be >>>>>>>>>>>>>>>> released independently, >>>>>>>>>>>>>>>> don't affect the core products >>>>>>>>>>>>>>>> are generic meaning they can be re-used. >>>>>>>>>>>>>>>> Optional for end users to use. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Cheers >>>>>>>>>>>>>>>> Mike >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Tim Bish >>>>>>>>>>>>>>> twitter: @tabish121 >>>>>>>>>>>>>>> blog: http://timbish.blogspot.com/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Clebert Suconic >>>>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Tim Bish >>>>>>>>>>> twitter: @tabish121 >>>>>>>>>>> blog: http://timbish.blogspot.com/ >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Tim Bish >>>>>>>>> twitter: @tabish121 >>>>>>>>> blog: http://timbish.blogspot.com/ >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> Clebert Suconic >>>>>>> >>>>>> >>>>> -- >>>>> Clebert Suconic >>>>> >>>> -- >>>> Clebert Suconic >>>> >> >> >> >> -- >> Clebert Suconic > > > > -- > Clebert Suconic
