activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Bish <tabish...@gmail.com>
Subject Re: [DISCUSS] Adding Derby as a dependency
Date Thu, 18 Jan 2018 18:43:56 GMT
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 <jbertram@apache.org> 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 <
>> 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 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 <jbertram@apache.org> 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 <
>>> 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
>>>>> <clebert.suconic@gmail.com> 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 <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
>>>>>
>>>>>
>>>>> --
>>>>> Clebert Suconic
>>>>>

-- 
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/


Mime
View raw message