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
