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
