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 Thu, 18 Jan 2018 22:18:45 GMT
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
<michael.andre.pearce@me.com> 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 <clebert.suconic@gmail.com> 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
>> <clebert.suconic@gmail.com> 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 <tabish121@gmail.com>
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 <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/
>>>>
>>> --
>>> Clebert Suconic
>>
>>
>>
>> --
>> Clebert Suconic



-- 
Clebert Suconic

Mime
View raw message