activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clebert Suconic <clebert.suco...@gmail.com>
Subject Re: [DISCUSS] Adding Derby as a dependency
Date Mon, 15 Jan 2018 14:44:41 GMT
@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 <mtaylor@redhat.com> 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 <
> 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 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 <clebert.suconic@gmail.com>
>> 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 <
>> > michael.andre.pearce@me.com> 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 <clebert.suconic@gmail.com>
>> >> wrote:
>> >>>
>> >>> We already have jdnc as a feature.
>> >>>
>> >>> On Sun, Jan 14, 2018 at 2:47 PM Michael André 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 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 <clebert.suconic@gmail.com
>> >
>> >>>> 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

Mime
View raw message