activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: Is skinning hawt.io enough to allow it be be packaged in ActiveMQ?
Date Mon, 27 Jan 2014 15:28:37 GMT
The user doesn't directly interact with Spring when they use AMQ.
It's not the "face" of AMQ.

On Mon, Jan 27, 2014 at 10:23 AM, Christian Posta
<christian.posta@gmail.com> wrote:
> What I'm supporting is the original comparison of the process needed
> to resolve issues with software developed by external communities. If
> it's not to the PMC's liking as HIram (and others) have mentioned,
> then we take steps to do something about it.
>
> We didn't write our own DI framework. If there were bugs in it then we
> would report them to Spring's community and work with their devs to
> fix it.
>
> If we built on top of Spring, then that's cool too. We are devs and
> can use other projects to leverage when it makes sense.
>
>
> On Mon, Jan 27, 2014 at 7:43 AM, Johan Edstrom <seijoed@gmail.com> wrote:
>> No, we wrote the NS handling and supporting classes to tie into those DI
>> frameworks, CXF, Camel, AMQ and so on has/have had support for
>> Blueprint, Spring, Guice, CDI and so on in various forms.
>>
>> Those weren't a "skinned" spring namespacehandler for camel residing
>> in a Spring repo with spring access so you can kinda cut that type of argument.
>>
>> What you are comparing is "supporting" libraries, as stated earlier, CXF for
>> example was heavily built on Spring, now not so heavily as it lead to deps
>> on spring that became incompatible with other 3rd party frameworks.
>>
>>
>> On Jan 27, 2014, at 9:37 AM, Christian Posta <christian.posta@gmail.com> wrote:
>>
>>> I guess the argument to be made is that the web console isn't a 3rd
>>> party library, it's a more involved part of the user experience. Which
>>> is true. But so is the Spring Framework. We didn't write our own DI
>>> framework for that.
>>>
>>> The point is the "process" to resolving any issues would be the same
>>> process we follow for any other outside community software we use.
>>>
>>>> If we the PMC does not like some detail of
>>>> hawtio we just need to open issues to address them and once it's to
>>>> the PMC's liking we can then package it.
>>>
>>>
>>> And this is exactly the way we've been doing it with other external
>>> community software.
>>>
>>>
>>>
>>> On Wed, Jan 22, 2014 at 3:44 PM, Hiram Chirino <hiram@hiramchirino.com>
wrote:
>>>> Starting up a new thread to avoid hijacking the original POLL thread.
>>>>
>>>> On Wed, Jan 22, 2014 at 5:29 PM, Hadrian Zbarcea <hzbarcea@gmail.com>
wrote:
>>>>> Without the hawt.io community donating the relevant ActiveMQ portions
to the
>>>>> ASF we will not be able to get a consensus around proposal #3. Thus,
that
>>>>> needs to be taken off the table.
>>>>
>>>> I think that's a faulty assumption that needs to get discussed and addressed.
>>>>
>>>> Any hawtio UI that we package in the ActiveMQ will be reviewed by the
>>>> PMC.  Like any 3rd party library that we ship, it has to have an
>>>> approved license and it's functionality has to be tested and verified
>>>> by the ActiveMQ project.  If we the PMC does not like some detail of
>>>> hawtio we just need to open issues to address them and once it's to
>>>> the PMC's liking we can then package it.  This is no different from
>>>> any other 3rd party lib we use so why are we treating it differently?
>>>>
>>>> --
>>>> Hiram Chirino
>>>
>>>
>>>
>>> --
>>> Christian Posta
>>> http://www.christianposta.com/blog
>>> twitter: @christianposta
>>
>
>
>
> --
> Christian Posta
> http://www.christianposta.com/blog
> twitter: @christianposta

Mime
View raw message