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 <[email protected]> wrote: > Well it kind of is. > > are we then saying if a third party lib in this case Derby DB implements an > interface that artemis provides in this case JDBC in the other case > ConnectorService we are happy to depend on it and ship it with artemis? > > I really don’t want to upset or annoy you but at the same time I really do > want an even playing field. > > As I already said I’m happy for artemis to have these. I think if someone is > willing to support it let it be there. If it ends up being unsupportable > remove it. Though that wasn’t the outcome from the last discussion. > > I really do think we need to have clear rules on this. That are generic about > any component, for anyone. > > eg if a component lies without someone maintaining then after 6months it goes > to inactive, if still after a year no one steps in it gets removed and moves > to an attic. > > > > Sent from my iPhone > >> On 15 Jan 2018, at 02:14, Clebert Suconic <[email protected]> wrote: >> >> That’s different. We are not implementing JDBC here. >> >> >> We can still provide a pluggavle interface and have the feature you wrote >> plugging into artemis. Even adding examples with dependencies towards it. >> I think it was agreed back then. >> >> >> That’s a different discussion from here though. >> >> On Sun, Jan 14, 2018 at 5:26 PM Michael André Pearce < >> [email protected]> wrote: >> >>> Yes. And JDBC the pluggable interface point, JDBC is the api. This is just >>> as ConnectorService is the pluggable interface that’s a feature. >>> >>> Either we have some provided implementations of the pluggable interfaces >>> that exist within artemis or none at all. >>> >>> I really see this as no different. I’m happy for it to be there, but then >>> I’d like this to applied in general, and to add the kafka ConnectorService. >>> >>> >>> >>> Sent from my iPhone >>> >>>> On 14 Jan 2018, at 21:05, Clebert Suconic <[email protected]> >>> wrote: >>>> >>>> We already have jdnc as a feature. >>>> >>>> On Sun, Jan 14, 2018 at 2:47 PM Michael André Pearce < >>>> [email protected]> wrote: >>>> >>>>> My two cents is about consistency of either we do provide integrations >>>>> with other products out the box or not. >>>>> >>>>> If the arguments of people not wanting to add Kafka clients to the class >>>>> path for ability to link Artemis with Kafka, because it means having to >>>>> maintain it (see it’s thread for all discussion), I don’t see why >>> linking >>>>> Artemis with a specific JDBC vendors product like Apache Derby is any >>>>> different here. >>>>> >>>>> Not that I’m against this, quite the contrary actually if I could add >>>>> Kafka integration, but I would like this ruling to be consistent. >>>>> >>>>> >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On 12 Jan 2018, at 23:51, Clebert Suconic <[email protected]> >>>>> wrote: >>>>>> >>>>>> I would like to add an option on artemis create to enable jdbc. >>>>>> >>>>>> >>>>>> By default (if you don't provide any other configuration) it will use >>>>>> derby by default on the properties. >>>>>> >>>>>> >>>>>> And I wanted to add derby as a dependency on ./lib >>>>>> >>>>>> >>>>>> Anyone against it? >>>>>> >>>>>> >>>>>> so, you would do ./artemis create --jdbc >>>>>> >>>>>> >>>>>> and it would configure derby as an option >>>>>> >>>>>> >>>>>> >>>>>> (JDBC is not encouraged.. the journal is the best option.. but same as >>>>>> in ActiveMQ5, some people need it). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> also: I'm trying to understand what I need to change on dep.xml under >>>>>> artemis-distribution, but I can't make it to work... anyone can give >>>>>> me a hand on that? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Clebert Suconic >>>>> >>>> -- >>>> Clebert Suconic >>> >> -- >> Clebert Suconic
