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