activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martyn Taylor <mtay...@redhat.com>
Subject Re: [DISCUSS] Adding Derby as a dependency
Date Mon, 15 Jan 2018 12:54:03 GMT
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 <
michael.andre.pearce@me.com> 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 <clebert.suconic@gmail.com>
> 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 <
> > michael.andre.pearce@me.com> 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 <clebert.suconic@gmail.com>
> >> wrote:
> >>>
> >>> We already have jdnc as a feature.
> >>>
> >>> On Sun, Jan 14, 2018 at 2:47 PM Michael André Pearce <
> >>> michael.andre.pearce@me.com> 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 <clebert.suconic@gmail.com
> >
> >>>> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message