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/
