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.po...@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 <seij...@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.po...@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 <hi...@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 <hzbar...@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
