From dev-return-63538-archive-asf-public=cust-asf.ponee.io@activemq.apache.org Thu Jan 18 23:40:39 2018 Return-Path: X-Original-To: archive-asf-public@eu.ponee.io Delivered-To: archive-asf-public@eu.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by mx-eu-01.ponee.io (Postfix) with ESMTP id A9D56180654 for ; Thu, 18 Jan 2018 23:40:39 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 96017160C2B; Thu, 18 Jan 2018 22:40:39 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 66E9A160C26 for ; Thu, 18 Jan 2018 23:40:38 +0100 (CET) Received: (qmail 75639 invoked by uid 500); 18 Jan 2018 22:40:37 -0000 Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@activemq.apache.org Delivered-To: mailing list dev@activemq.apache.org Received: (qmail 75616 invoked by uid 99); 18 Jan 2018 22:40:37 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Jan 2018 22:40:37 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id B4185180161 for ; Thu, 18 Jan 2018 22:40:36 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.88 X-Spam-Level: X-Spam-Status: No, score=0.88 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KAM_LIVE=1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id A-iUXkpFv6Bo for ; Thu, 18 Jan 2018 22:40:33 +0000 (UTC) Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com [209.85.215.51]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id D71BF5F341 for ; Thu, 18 Jan 2018 22:40:32 +0000 (UTC) Received: by mail-lf0-f51.google.com with SMTP id q194so17208750lfe.13 for ; Thu, 18 Jan 2018 14:40:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=cWtkG8IzvvVA/PNsoF6Bg7P2INJa//Ak+H1Y7JoRYXI=; b=rFwToOs/2TeOTGQn9k+bXk+6Mzfab8pcWIrXAEBR67HSO26qiJlZW8PCf7as8HbOLE W7l4Wx7GT0TK9H0hfbKh8MsBcjP5lIhMh3fmFh7t7jvBb3kNE1D6dfUroqmnXVwysHTF LCd7kpg0AcBoplLgEoj+PlDzVvhuqZMCy3S5H+AkNomUDC2Ct+7FilW0RPlRHdcnnn6s 4XMK8syOGNchPItJZ3iK9OVxLIcJqHdd3ogHR8mNrI55TjDhfgSbtWhFRh/6aBouplzG pQRVxuBQfchyzMCG4Lupz8+fVYBfDtlMFui7iAjBGeR43fHK9XICAu//VS7xjBywKEEQ jd8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=cWtkG8IzvvVA/PNsoF6Bg7P2INJa//Ak+H1Y7JoRYXI=; b=o7KAyorDk8q93SJG43O0IZ4MoasN+cn8z7XPGz2xZ3pKS5JgyuqACZTlvc81pnmAGK h+sbnOgz5PODIq+sRL1eei+SE7DlECzUoAKiM2/phKiZgYpNsVj4npQbgv407dI7Ppvj yXI1u0Tqk+TdSlfKzKy9kSSit38KwacV3St1ipGUSyswukyP3EBK5XPDYrxCJqXi5lHI Ag/lCiHU9Pa+YpMehtymvqhf9uXirMhQlrNGGH5B/Atfw9cXRNZRGWqa0rPvGQhkjQs7 SEFC9zaaFsp4MZArnV8+3n1narQrqLurhfgocSi5vBqGgr9RiLgc+Qtd8YIIuabiQvr/ 21hw== X-Gm-Message-State: AKwxytdksDIOvKqkw+FYqkP3V0iEAXKD9WOo6j2wlwmALkkYejgXtpi8 C6MP5aNhU0nU4nmX+iRCtO4JXNytsSBiOV9RB4Ygyw== X-Google-Smtp-Source: ACJfBotsC3Pp21CsA+qBv0z/0hhZmcmUbW6CySG26+9NzlbFZmflJBo83pd8Y1k26S2sGBOz08QIZkMCsW7o6IvzYfI= X-Received: by 10.25.21.163 with SMTP id 35mr12050812lfv.2.1516315225385; Thu, 18 Jan 2018 14:40:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.42.193 with HTTP; Thu, 18 Jan 2018 14:40:24 -0800 (PST) In-Reply-To: References: <83215C6D-4E18-489E-A090-A6BBE7395313@me.com> <2E1521BD-13F2-4CDB-880A-06363228943E@me.com> <823f8d89-190b-ab36-8560-36a482724512@gmail.com> <8A011D66-BEFF-42A3-A026-6386E6881554@me.com> From: Clebert Suconic Date: Thu, 18 Jan 2018 17:40:24 -0500 Message-ID: Subject: Re: [DISCUSS] Adding Derby as a dependency To: dev@activemq.apache.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Actually, I will keep this as is.. .the user should decide what driver to u= se... 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 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=C3=A9 Pearce > wrote: >> Just for the record I gave an opinion in a discussion, I have not given = a -1. >> >> I=E2=80=99m not veto or blocking anything. >> >> In actual fact as I said I=E2=80=99m for this I think it=E2=80=99s 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 a= dded if remotely have their own lifecycle. At the moment it=E2=80=99s quite= obvious it=E2=80=99s unclear. >> >> >> >> Sent from my iPhone >> >>> On 18 Jan 2018, at 21:31, Clebert Suconic w= rote: >>> >>> 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-SNAPS= HOT-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 >>> 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 wr= ote: >>>>> >>>>> Agree with Robbie on this. My view from the previous discussion on t= he >>>>> 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 d= o >>>>> 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 J= DBC >>>>> 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 the= ir >>>>> 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 option= al >>>>> folder or the like in the 'lib' folder to make it clear to those >>>>> maintaining a broker installation who are averse to keeping unused bi= ts >>>>> 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 n= ot >>>>>> 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 wr= ote: >>>>>>>> ...if I made the connector implementation code available in maven >>>>>>>> central >>>>>>> will have it hosted in GitHub the source, then we=E2=80=99d be happ= y to have >>>>>>> that >>>>>>> packaged in to provide the functionality? >>>>>>> >>>>>>> Obviously I can only speak for myself here, but that's how I unders= tood >>>>>>> the >>>>>>> previous discussion. >>>>>>> >>>>>>> >>>>>>> Justin >>>>>>> >>>>>>> On Thu, Jan 18, 2018 at 10:53 AM, Michael Andr=C3=A9 Pearce < >>>>>>> michael.andre.pearce@me.com> 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 sourc= e, >>>>>>>> then >>>>>>>> we=E2=80=99d be happy to have that packaged in to provide the func= tionality? >>>>>>>> >>>>>>>> If that=E2=80=99s the case im +1 with this, and then I=E2=80=99ll = work on doing that >>>>>>>> for >>>>>>>> the Kafka piece then. >>>>>>>> >>>>>>>> Cheers >>>>>>>> Mike >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>>> On 18 Jan 2018, at 17:47, Justin Bertram wr= ote: >>>>>>>>> >>>>>>>>> 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 th= e >>>>>>>> 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) b= ut >>>>>>>> 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. Th= is >>>>>>>>> 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 i= n >>>>>>>>> via >>>>>>>>> Maven. If your Kafka connector was available via Maven and we wa= nted >>>>>>>>> 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 < >>>>>>>> clebert.suconic@gmail.com> >>>>>>>>> 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 >>>>>>>>>> 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 int= o >>>>>>>>>>> lib. >>>>>>>>>>> I changed dep.xml but it's not picking it up. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mon, Jan 15, 2018 at 7:54 AM, Martyn Taylor >>>>>>>>>> wrote: >>>>>>>>>>>> Michael, >>>>>>>>>>>> >>>>>>>>>>>> I think all Clebert is suggesting here is to have something th= at >>>>>>>>>>>> works >>>>>>>>>> out >>>>>>>>>>>> the box to demonstrate the JDBC store. Derby is a good candid= ate >>>>>>>>>>>> as >>>>>>>> it >>>>>>>>>> can >>>>>>>>>>>> work in memory, and we it in a lot in our tests. I've actuall= y >>>>>>>>>>>> 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 servic= e >>>>>>>>>>>> implementation? The only Derby specific thing here would be t= o >>>>>>>>>>>> ship >>>>>>>> the >>>>>>>>>>>> lib as part of the distro and to configure a JDBC URL. I gues= s 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 a= nd >>>>>>>>>>>> test >>>>>>>>>>>> Artemis + JDBC sounds like a UX win to me. >>>>>>>>>>>> >>>>>>>>>>>> Cheers >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Jan 15, 2018 at 7:24 AM, Michael Andr=C3=A9 Pearce < >>>>>>>>>>>> michael.andre.pearce@me.com> 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 o= ther >>>>>>>> case >>>>>>>>>>>>> ConnectorService we are happy to depend on it and ship it wit= h >>>>>>>> artemis? >>>>>>>>>>>>> I really don=E2=80=99t want to upset or annoy you but at the = same time I >>>>>>>>>> really do >>>>>>>>>>>>> want an even playing field. >>>>>>>>>>>>> >>>>>>>>>>>>> As I already said I=E2=80=99m 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=E2=80=99t the outcome from the la= st >>>>>>>>>>>>> discussion. >>>>>>>>>>>>> >>>>>>>>>>>>> I really do think we need to have clear rules on this. That a= re >>>>>>>> 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 ge= ts >>>>>>>>>> removed and >>>>>>>>>>>>> moves to an attic. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>>> >>>>>>>>>>>>>> On 15 Jan 2018, at 02:14, Clebert Suconic < >>>>>>>> clebert.suconic@gmail.com >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> That=E2=80=99s different. We are not implementing JDBC here. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> We can still provide a pluggavle interface and have the feat= ure >>>>>>>>>>>>>> you >>>>>>>>>> wrote >>>>>>>>>>>>>> plugging into artemis. Even adding examples with dependenci= es >>>>>>>>>> towards >>>>>>>>>>>>> it. >>>>>>>>>>>>>> I think it was agreed back then. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> That=E2=80=99s a different discussion from here though. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sun, Jan 14, 2018 at 5:26 PM Michael Andr=C3=A9 Pearce < >>>>>>>>>>>>>> michael.andre.pearce@me.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes. And JDBC the pluggable interface point, JDBC is the ap= i. >>>>>>>>>>>>>>> This >>>>>>>>>> is >>>>>>>>>>>>> just >>>>>>>>>>>>>>> as ConnectorService is the pluggable interface that=E2=80= =99s a >>>>>>>>>>>>>>> feature. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Either we have some provided implementations of the pluggab= le >>>>>>>>>> interfaces >>>>>>>>>>>>>>> that exist within artemis or none at all. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I really see this as no different. I=E2=80=99m happy for it= to be >>>>>>>>>>>>>>> there, >>>>>>>> but >>>>>>>>>>>>> then >>>>>>>>>>>>>>> I=E2=80=99d 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 < >>>>>>>>>> clebert.suconic@gmail.com> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> We already have jdnc as a feature. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Sun, Jan 14, 2018 at 2:47 PM Michael Andr=C3=A9 Pearce = < >>>>>>>>>>>>>>>> michael.andre.pearce@me.com> 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 clien= ts >>>>>>>>>>>>>>>>> to >>>>>>>> the >>>>>>>>>>>>> class >>>>>>>>>>>>>>>>> path for ability to link Artemis with Kafka, because it m= eans >>>>>>>>>> having >>>>>>>>>>>>> to >>>>>>>>>>>>>>>>> maintain it (see it=E2=80=99s thread for all discussion),= I don=E2=80=99t see >>>>>>>>>>>>>>>>> why >>>>>>>>>>>>>>> linking >>>>>>>>>>>>>>>>> Artemis with a specific JDBC vendors product like Apache >>>>>>>>>>>>>>>>> Derby is >>>>>>>>>> any >>>>>>>>>>>>>>>>> different here. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Not that I=E2=80=99m against this, quite the contrary act= ually 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 < >>>>>>>>>> clebert.suconic@gmail.com >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> I would like to add an option on artemis create to enabl= e >>>>>>>>>>>>>>>>>> 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... any= one >>>>>>>>>>>>>>>>>> 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 --=20 Clebert Suconic