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 <johndam...@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 <clebert.suco...@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.suco...@gmail.com >> > >> wrote: >> >> > On Wed, Jun 21, 2017 at 2:16 PM John D. Ament <johndam...@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.suco...@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 <johndam...@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 <tabish...@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 <tabish...@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.tayl...@gmail.com >> >> > > >> >> > > > wrote: >> >> > > > >>> >> >> > > > >>>> The JMS connection Pool currently in ActiveMQ could live >> there >> >> > > > >>>> >> >> > > > >>>> On 9 June 2017 at 04:52, Clebert Suconic < >> >> > clebert.suco...@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 < >> >> > tabish...@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
