[DISCUSS] Adding Derby as a dependency

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] Adding Derby as a dependency

clebertsuconic
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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Adding Derby as a dependency

MichaelAndrePearce
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Adding Derby as a dependency

clebertsuconic
We already have jdnc as a feature.

On Sun, Jan 14, 2018 at 2:47 PM Michael André Pearce <
[hidden email]> 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 <[hidden email]>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Adding Derby as a dependency

MichaelAndrePearce
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 <[hidden email]> wrote:
>
> We already have jdnc as a feature.
>
> On Sun, Jan 14, 2018 at 2:47 PM Michael André Pearce <
> [hidden email]> 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 <[hidden email]>
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Adding Derby as a dependency

clebertsuconic
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 <
[hidden email]> 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 <[hidden email]>
> wrote:
> >
> > We already have jdnc as a feature.
> >
> > On Sun, Jan 14, 2018 at 2:47 PM Michael André Pearce <
> > [hidden email]> 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 <[hidden email]>
> >> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Adding Derby as a dependency

MichaelAndrePearce
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 <[hidden email]> 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 <
> [hidden email]> 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 <[hidden email]>
>> wrote:
>>>
>>> We already have jdnc as a feature.
>>>
>>> On Sun, Jan 14, 2018 at 2:47 PM Michael André Pearce <
>>> [hidden email]> 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 <[hidden email]>
>>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Adding Derby as a dependency

Robbie Gemmell
I'd first wonder if Clebert was talking about pre baked embedded-Derby
usage rather than client-server Derby, where it directly creates files
on local disk and manages them, i.e. acting somewhat like the journal
but giving the option for storage still accessable later via JDBC
(though without any network hops while in use). If so then that seems
reasonable enough (and matches whats done in another messaging system
I'm familiar with), though I could go either way on whether to
actually do it. If not then it wouldn't personally.

I was one of the people in the previous threads who thought any Kafka
bridge should be maintained outside the main broker repo and
distribution, regardless where that place was, and I still think such
a component having its own independent lifecycle makes the most sense.
I dont think these two particular situations are quite as similar as
it seems you do. Providing durable storage for messages etc is basic
core functionality of the broker to me, whereas bridging messages to a
particular different messaging system seems more of a standalone
extension. It would be more logical for a self-contained example of
the the former to ship as part of the broker than it ever would for
the latter in my mind. Also, in these specific cases there would
presumably also be minimal code to maintain in the former since it
essentially already exists and isnt really a new component on its own
(though itd still becomes something specific to test, admittedly),
plus it uses a standard Java API giving a reduced liklihood of any
hassle around versioning than the latter could present.

Robbie

On 15 January 2018 at 07:24, Michael André Pearce
<[hidden email]> 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 <[hidden email]> 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 <
>> [hidden email]> 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 <[hidden email]>
>>> wrote:
>>>>
>>>> We already have jdnc as a feature.
>>>>
>>>> On Sun, Jan 14, 2018 at 2:47 PM Michael André Pearce <
>>>> [hidden email]> 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 <[hidden email]>
>>>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Adding Derby as a dependency

Martyn Taylor
In reply to this post by MichaelAndrePearce
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 <
[hidden email]> 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 <[hidden email]>
> 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 <
> > [hidden email]> 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 <[hidden email]>
> >> wrote:
> >>>
> >>> We already have jdnc as a feature.
> >>>
> >>> On Sun, Jan 14, 2018 at 2:47 PM Michael André Pearce <
> >>> [hidden email]> 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 <[hidden email]
> >
> >>>> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Adding Derby as a dependency

clebertsuconic
@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 <[hidden email]> 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 <
> [hidden email]> 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 <[hidden email]>
>> 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 <
>> > [hidden email]> 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 <[hidden email]>
>> >> wrote:
>> >>>
>> >>> We already have jdnc as a feature.
>> >>>
>> >>> On Sun, Jan 14, 2018 at 2:47 PM Michael André Pearce <
>> >>> [hidden email]> 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 <[hidden email]
>> >
>> >>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Adding Derby as a dependency

clebertsuconic
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
<[hidden email]> 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 <[hidden email]> 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 <
>> [hidden email]> 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 <[hidden email]>
>>> 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 <
>>> > [hidden email]> 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 <[hidden email]>
>>> >> wrote:
>>> >>>
>>> >>> We already have jdnc as a feature.
>>> >>>
>>> >>> On Sun, Jan 14, 2018 at 2:47 PM Michael André Pearce <
>>> >>> [hidden email]> 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 <[hidden email]
>>> >
>>> >>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Adding Derby as a dependency

jbertram
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 <[hidden email]>
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
> <[hidden email]> 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 <[hidden email]>
> 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 <
> >> [hidden email]> 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 <[hidden email]
> >
> >>> 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 <
> >>> > [hidden email]> 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 <
> [hidden email]>
> >>> >> wrote:
> >>> >>>
> >>> >>> We already have jdnc as a feature.
> >>> >>>
> >>> >>> On Sun, Jan 14, 2018 at 2:47 PM Michael André Pearce <
> >>> >>> [hidden email]> 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 <
> [hidden email]
> >>> >
> >>> >>>> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Adding Derby as a dependency

MichaelAndrePearce
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 <[hidden email]> 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 <[hidden email]>
> 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
>> <[hidden email]> 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 <[hidden email]>
>> 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 <
>>>> [hidden email]> 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 <[hidden email]
>>>
>>>>> 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 <
>>>>>> [hidden email]> 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 <
>> [hidden email]>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> We already have jdnc as a feature.
>>>>>>>>
>>>>>>>> On Sun, Jan 14, 2018 at 2:47 PM Michael André Pearce <
>>>>>>>> [hidden email]> 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 <
>> [hidden email]
>>>>>>
>>>>>>>>> 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
>>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Adding Derby as a dependency

jbertram
> ...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 <
[hidden email]> 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 <[hidden email]> 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 <
> [hidden email]>
> > 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
> >> <[hidden email]> 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 <[hidden email]>
> >> 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 <
> >>>> [hidden email]> 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 <
> [hidden email]
> >>>
> >>>>> 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 <
> >>>>>> [hidden email]> 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 <
> >> [hidden email]>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> We already have jdnc as a feature.
> >>>>>>>>
> >>>>>>>> On Sun, Jan 14, 2018 at 2:47 PM Michael André Pearce <
> >>>>>>>> [hidden email]> 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 <
> >> [hidden email]
> >>>>>>
> >>>>>>>>> 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
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Adding Derby as a dependency

clebertsuconic
In reply to this post by jbertram
On Thu, Jan 18, 2018 at 11:47 AM, Justin Bertram <[hidden email]> wrote:

> 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.


I'm not sure if you asked a +1 from me or Michael.. but that's exactly
what I think... we could still consume Michael's component somewhere.
The issue was about the release cycle.

I even offered to have it depending on a example.. showing how it
could be integrated.
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Adding Derby as a dependency

Robbie Gemmell
In reply to this post by jbertram
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 <[hidden email]> 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 <
> [hidden email]> 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 <[hidden email]> 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 <
>> [hidden email]>
>> > 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
>> >> <[hidden email]> 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 <[hidden email]>
>> >> 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 <
>> >>>> [hidden email]> 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 <
>> [hidden email]
>> >>>
>> >>>>> 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 <
>> >>>>>> [hidden email]> 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 <
>> >> [hidden email]>
>> >>>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>> We already have jdnc as a feature.
>> >>>>>>>>
>> >>>>>>>> On Sun, Jan 14, 2018 at 2:47 PM Michael André Pearce <
>> >>>>>>>> [hidden email]> 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 <
>> >> [hidden email]
>> >>>>>>
>> >>>>>>>>> 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
>> >>
>>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Adding Derby as a dependency

jbertram
Clebert, I was looking for a +1 from Mike.  My understanding is that a -1
from a committer (or is it just PMC?) is a veto [1], and I felt that was
Mike's position.  I think your PR is a good one and I'd like to merge it
ASAP.

Anybody feel free to correct me if I'm wrong on the veto thing.


Justin

[1] https://www.apache.org/foundation/voting.html#votes-on-code-modification

On Thu, Jan 18, 2018 at 11:47 AM, Robbie Gemmell <[hidden email]>
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 <[hidden email]> 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 <
> > [hidden email]> 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 <[hidden email]> 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 <
> >> [hidden email]>
> >> > 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
> >> >> <[hidden email]> 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 <[hidden email]>
> >> >> 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 <
> >> >>>> [hidden email]> 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 <
> >> [hidden email]
> >> >>>
> >> >>>>> 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 <
> >> >>>>>> [hidden email]> 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 <
> >> >> [hidden email]>
> >> >>>>>>> wrote:
> >> >>>>>>>>
> >> >>>>>>>> We already have jdnc as a feature.
> >> >>>>>>>>
> >> >>>>>>>> On Sun, Jan 14, 2018 at 2:47 PM Michael André Pearce <
> >> >>>>>>>> [hidden email]> 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 <
> >> >> [hidden email]
> >> >>>>>>
> >> >>>>>>>>> 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
> >> >>
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Adding Derby as a dependency

artnaseef
In reply to this post by Robbie Gemmell
If I'm understanding the discussion well enough (apologies, TLDR) - one
concern with adding this directly into core Artemis is ending up with too
much complexity baked into the main product.  Also, Mixing Concerns (i.e.
reduced "separation of concerns").

Having a downstream project that integrates the two seems like a good way
to reach the end goal.  Yes, that means that downstream project may not
always be kept up-to-date.... Would that really be a concern?

On the providing core persistence - that is core to Artemis, and Artemis
provides a reasonable solution to that problem out-of-the-box.  There are
dozens, if not hundreds, or alternatives we could add as near-storage.
There needs to be a clear line on that front.  Not sure I understand why
anyone wants JDBC access to their messaging solution internal storage in my
not-so-humble opinion.  They (JDBC and messaging) serve two very different
patterns and problem-sets.

My 2 cents. HTH

Art


On Thu, Jan 18, 2018 at 10:47 AM, Robbie Gemmell <[hidden email]>
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 <[hidden email]> 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 <
> > [hidden email]> 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 <[hidden email]> 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 <
> >> [hidden email]>
> >> > 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
> >> >> <[hidden email]> 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 <[hidden email]>
> >> >> 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 <
> >> >>>> [hidden email]> 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 <
> >> [hidden email]
> >> >>>
> >> >>>>> 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 <
> >> >>>>>> [hidden email]> 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 <
> >> >> [hidden email]>
> >> >>>>>>> wrote:
> >> >>>>>>>>
> >> >>>>>>>> We already have jdnc as a feature.
> >> >>>>>>>>
> >> >>>>>>>> On Sun, Jan 14, 2018 at 2:47 PM Michael André Pearce <
> >> >>>>>>>> [hidden email]> 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 <
> >> >> [hidden email]
> >> >>>>>>
> >> >>>>>>>>> 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
> >> >>
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Adding Derby as a dependency

clebertsuconic
On Thu, Jan 18, 2018 at 1:12 PM, Arthur Naseef <[hidden email]> wrote:
> On the providing core persistence - that is core to Artemis, and Artemis
> provides a reasonable solution to that problem out-of-the-box.  There are
> dozens, if not hundreds, or alternatives we could add as near-storage.
> There needs to be a clear line on that front.  Not sure I understand why
> anyone wants JDBC access to their messaging solution internal storage in my
> not-so-humble opinion.  They (JDBC and messaging) serve two very different
> patterns and problem-sets.

JDBC is already a feature.. I'm just providing easier configuration
out of the box with a simple CLI tool.
We are not discussin if we should have JDBC or not.


We had to add because users *wanted it*. No other reason.


as they say.. the "customer" is always right :)
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Adding Derby as a dependency

tabish121@gmail.com
In reply to this post by Robbie Gemmell
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 <[hidden email]> 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 <
>> [hidden email]> 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 <[hidden email]> 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 <
>>> [hidden email]>
>>>> 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
>>>>> <[hidden email]> 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 <[hidden email]>
>>>>> 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 <
>>>>>>> [hidden email]> 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 <
>>> [hidden email]
>>>>>>>> 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 <
>>>>>>>>> [hidden email]> 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 <
>>>>> [hidden email]>
>>>>>>>>>> wrote:
>>>>>>>>>>> We already have jdnc as a feature.
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Jan 14, 2018 at 2:47 PM Michael André Pearce <
>>>>>>>>>>> [hidden email]> 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 <
>>>>> [hidden email]
>>>>>>>>>>>> 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/

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Adding Derby as a dependency

clebertsuconic
I will remove the dependency to avoid confusion.

The database example will download the derby driver and install it on the
lib.


I will also add a message during the broker creation telling the user to
copy the driver in the right place.


On Thu, Jan 18, 2018 at 1:44 PM Timothy Bish <[hidden email]> wrote:

> 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 <[hidden email]> 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 <
> >> [hidden email]> 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 <[hidden email]> 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 <
> >>> [hidden email]>
> >>>> 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
> >>>>> <[hidden email]> 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 <[hidden email]>
> >>>>> 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 <
> >>>>>>> [hidden email]> 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 <
> >>> [hidden email]
> >>>>>>>> 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 <
> >>>>>>>>> [hidden email]> 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 <
> >>>>> [hidden email]>
> >>>>>>>>>> wrote:
> >>>>>>>>>>> We already have jdnc as a feature.
> >>>>>>>>>>>
> >>>>>>>>>>> On Sun, Jan 14, 2018 at 2:47 PM Michael André Pearce <
> >>>>>>>>>>> [hidden email]> 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 <
> >>>>> [hidden email]
> >>>>>>>>>>>> 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/
>
> --
Clebert Suconic
12