Agree with Robbie on this. My view from the previous discussion on the
Kafka bridge is that is would be a third party project that could be
used by anyone that wished to have it but that it does not need to be
(or should be) included with the broker either in the repo or the
distribution. Third party tools / plugins can live on their own and
provide their own documentation / examples for their use and
installation into the broker. I think we covered this in the past
discussion fairly well.
As for the Derby bits being added I'm not entirely against it but I do
think that it would be rare for anyone to actually end up using it in
any sort of production type scenarios. Most folks that want to use JDBC
have existing DB instances that provides some feature that they feel
requires them to use a JDBC store and will use a JDBC driver from their
vendor for that. We don't include derby in the 5.x distribution
although we do use it for testing the JDBC store. If you do include
derby in the distribution you should probably include it in an optional
folder or the like in the 'lib' folder to make it clear to those
maintaining a broker installation who are averse to keeping unused bits
around that it can be deleted without an ill affects on the broker.
On 01/18/2018 12:47 PM, Robbie Gemmell wrote:
I can't speak for others on the previous thread, but the below was not
my position in that prior discussion at all. I don't think the
proposed kafka bridge component should be bundled in the broker repo
or distribution, regardless where else the code lives, but that it
should instead have its own independent lifecyle and distribution.
I think I already covered, at least in part, in my earlier mail on
this thread why I actually see these as different situations.
Robbie
On 18 January 2018 at 17:06, Justin Bertram <[email protected]> wrote:
...if I made the connector implementation code available in maven central
will have it hosted in GitHub the source, then we’d be happy to have that
packaged in to provide the functionality?
Obviously I can only speak for myself here, but that's how I understood the
previous discussion.
Justin
On Thu, Jan 18, 2018 at 10:53 AM, Michael André Pearce <
[email protected]> wrote:
Ok so if I understood this if I made the connector implementation code
available in maven central will have it hosted in GitHub the source, then
we’d be happy to have that packaged in to provide the functionality?
If that’s the case im +1 with this, and then I’ll work on doing that for
the Kafka piece then.
Cheers
Mike
Sent from my iPhone
On 18 Jan 2018, at 17:47, Justin Bertram <[email protected]> wrote:
I just reviewed your PR, Clebert, and made a comment. In general I think
it looks great. Nice work.
I've been thinking about your concern, Michael, that the rules on
integrations like this aren't clear. I went back and reviewed the
mailing
list discussion and the discussion on your PR for the Kafka integration
using the ConnectorService. As far as I can tell, the main issue with
your
PR was that many didn't want to house the actual implementation-specific
integration code within the Artemis project. It seems to me that this
"rule" is being applied consistently in this case as well, namely that
Artemis is providing an integration point (i.e. the JDBC layer) but
doesn't
house implementation-specific code (i.e. Derby).
The consensus in our previous discussion was that implementation-specific
integration code (e.g. your Kafka connector) should live outside the
broker
code-base as a separate component with its own release cycle. This is
exactly how the integration with Derby is working. Derby lives outside
the
broker code-base with its own release cycle and is being pulled in via
Maven. If your Kafka connector was available via Maven and we wanted to
create a broker example that used it I don't think that would be an
issue.
To be clear, Derby is being packaged with the broker to serve as a
default
JDBC implementation, but I don't think it would be an issue to package
the
Kafka connector with the broker if there was a similar, real need.
I don't see any contradictions or inequities here. I'd like to confirm a
+1 from you before I merge. Let me know what you think.
Justin
On Mon, Jan 15, 2018 at 1:53 PM, Clebert Suconic <
[email protected]>
wrote:
I am almost done with this.. I should be able to send a PR tomorrow..
I think it's looking nice.
On Mon, Jan 15, 2018 at 9:44 AM, Clebert Suconic
<[email protected]> wrote:
@Martyn: That's exactly what I'm planning.. Having the embedded
Derby.. just for out of box testing.
someone would do ./artemis create --jdbc ./server-place
and we would have artemis running with Derby right there.
Now my question here was... where do we change to add stuff into lib.
I changed dep.xml but it's not picking it up.
On Mon, Jan 15, 2018 at 7:54 AM, Martyn Taylor <[email protected]>
wrote:
Michael,
I think all Clebert is suggesting here is to have something that works
out
the box to demonstrate the JDBC store. Derby is a good candidate as
it
can
work in memory, and we it in a lot in our tests. I've actually not
talked
to Clebert about this, so he can confirm/deny if this was his intent,
but I
don't see this being related to maintaining a connector service
implementation? The only Derby specific thing here would be to ship
the
lib as part of the distro and to configure a JDBC URL. I guess we
could
ask for a JDBC URL as part of the prompt, and tell the user to drop
the
lib
on the class path, but having a quick and easy way to set up and test
Artemis + JDBC sounds like a UX win to me.
Cheers
On Mon, Jan 15, 2018 at 7:24 AM, Michael André Pearce <
[email protected]> wrote:
Well it kind of is.
are we then saying if a third party lib in this case Derby DB
implements
an interface that artemis provides in this case JDBC in the other
case
ConnectorService we are happy to depend on it and ship it with
artemis?
I really don’t want to upset or annoy you but at the same time I
really do
want an even playing field.
As I already said I’m happy for artemis to have these. I think if
someone
is willing to support it let it be there. If it ends up being
unsupportable
remove it. Though that wasn’t the outcome from the last discussion.
I really do think we need to have clear rules on this. That are
generic
about any component, for anyone.
eg if a component lies without someone maintaining then after 6months
it
goes to inactive, if still after a year no one steps in it gets
removed and
moves to an attic.
Sent from my iPhone
On 15 Jan 2018, at 02:14, Clebert Suconic <
[email protected]
wrote:
That’s different. We are not implementing JDBC here.
We can still provide a pluggavle interface and have the feature you
wrote
plugging into artemis. Even adding examples with dependencies
towards
it.
I think it was agreed back then.
That’s a different discussion from here though.
On Sun, Jan 14, 2018 at 5:26 PM Michael André Pearce <
[email protected]> wrote:
Yes. And JDBC the pluggable interface point, JDBC is the api. This
is
just
as ConnectorService is the pluggable interface that’s a feature.
Either we have some provided implementations of the pluggable
interfaces
that exist within artemis or none at all.
I really see this as no different. I’m happy for it to be there,
but
then
I’d like this to applied in general, and to add the kafka
ConnectorService.
Sent from my iPhone
On 14 Jan 2018, at 21:05, Clebert Suconic <
[email protected]>
wrote:
We already have jdnc as a feature.
On Sun, Jan 14, 2018 at 2:47 PM Michael André Pearce <
[email protected]> wrote:
My two cents is about consistency of either we do provide
integrations
with other products out the box or not.
If the arguments of people not wanting to add Kafka clients to
the
class
path for ability to link Artemis with Kafka, because it means
having
to
maintain it (see it’s thread for all discussion), I don’t see why
linking
Artemis with a specific JDBC vendors product like Apache Derby is
any
different here.
Not that I’m against this, quite the contrary actually if I could
add
Kafka integration, but I would like this ruling to be consistent.
Sent from my iPhone
On 12 Jan 2018, at 23:51, Clebert Suconic <
[email protected]
wrote:
I would like to add an option on artemis create to enable jdbc.
By default (if you don't provide any other configuration) it
will use
derby by default on the properties.
And I wanted to add derby as a dependency on ./lib
Anyone against it?
so, you would do ./artemis create --jdbc
and it would configure derby as an option
(JDBC is not encouraged.. the journal is the best option.. but
same
as
in ActiveMQ5, some people need it).
also: I'm trying to understand what I need to change on dep.xml
under
artemis-distribution, but I can't make it to work... anyone can
give
me a hand on that?
--
Clebert Suconic
--
Clebert Suconic
--
Clebert Suconic
--
Clebert Suconic
--
Clebert Suconic
--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/
