Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of christian.posta@gmail.com
 designates 209.85.215.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <20BABBF1-24DA-474D-8576-9557F1C948F3@gmail.com>
References: 
 <CAGZ-RDLhqnKMrguGLmB=B_EFDq-NaN9mi7FNieoJgQb+T8jm8A@mail.gmail.com>
	<CAKS7T5MUsZgd1hEP8iWcF8GQy7HhhDOWDATERmn6xwsyA3d4Sw@mail.gmail.com>
	<20BABBF1-24DA-474D-8576-9557F1C948F3@gmail.com>
Date: Mon, 27 Jan 2014 08:23:07 -0700
Message-ID: 
 <CAKS7T5ORimkz3cdq=CV=SOXpCG6SZ1BJt6Umd25tntoXKiUXqQ@mail.gmail.com>
Subject: Re: Is skinning hawt.io enough to allow it be be packaged in
 ActiveMQ?
From: Christian Posta <christian.posta@gmail.com>
To: "dev@activemq.apache.org" <dev@activemq.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

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