Actually, I will keep this as is.. .the user should decide what driver to use...
I will keep configurations by default as derby (if the user doesn't provide anything else on the CLI).. but that's just for easy of use. On Thu, Jan 18, 2018 at 5:18 PM, Clebert Suconic <[email protected]> wrote: > thanks.. it's all good... > > > Actually I think not having the dependency on the main lib was a good > outcome anyways... > > > I could make a further change.. to programmatically download derby if > the user allows it. > > On Thu, Jan 18, 2018 at 5:02 PM, Michael André Pearce > <[email protected]> wrote: >> Just for the record I gave an opinion in a discussion, I have not given a -1. >> >> I’m not veto or blocking anything. >> >> In actual fact as I said I’m for this I think it’s good. >> >> just I think as a community we should have some clear guidelines agreed of >> what goes in and what stays out, and how some things are allowed to be added >> if remotely have their own lifecycle. At the moment it’s quite obvious it’s >> unclear. >> >> >> >> Sent from my iPhone >> >>> On 18 Jan 2018, at 21:31, Clebert Suconic <[email protected]> wrote: >>> >>> so, after my last update, >>> >>> When you create a server with the --jdbc option >>> >>> example: >>> >>> >>> ./artemis create /tmp/myserver --jdbc >>> >>> >>> >>> the CLI will still help the user to configure the server... but >>> instead of having the dependency ready, it will give you the following >>> message: >>> >>> >>> ******************************************************************************** >>> >>> >>> Copy a jar containing the JDBC Driver >>> 'org.apache.derby.jdbc.EmbeddedDriver' into >>> /work/apache/six/artemis-distribution/target/apache-artemis-2.5.0-SNAPSHOT-bin/apache-artemis-2.5.0-SNAPSHOT/bin/xxx/lib >>> >>> >>> ******************************************************************************** >>> >>> >>> >>> >>> The example will download it through maven dependencies.. and install >>> it at the created server/lib. >>> >>> >>> On Thu, Jan 18, 2018 at 2:02 PM, Clebert Suconic >>> <[email protected]> wrote: >>>> 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 >>> >>> >>> >>> -- >>> Clebert Suconic > > > > -- > Clebert Suconic -- Clebert Suconic
