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
