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