You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Robert Davies <ra...@gmail.com> on 2014/01/17 14:33:36 UTC
[POLL] - Remove the old ActiveMQ Console
I want to take a straw poll to see where everyone stands, because opinion has varied, mine included. Straw polls can be a useful tool to move towards consensus. This isn’t a formal vote, but to reduce the noise, can we keep it to binding votes only ?
1. Have one distribution with no default console, but make it easy to deploy a console on demand (the original console - or 3rd party ones).
2. Have two separate distributions, one with no console - and have a second distribution with the original console
3. One distribution, with hawtio as the console - ActiveMQ branded.
4. One distribution, but uses the original ActiveMQ console only.
Here’s my vote:
[1]. +1
[2] 0
[3] 0
[4] -1
thanks,
Rob
Re: [POLL] - Remove the old ActiveMQ Console
Posted by James Carman <ja...@carmanconsulting.com>.
I said console in my statement, not web console. You need a way to manage
stuff.
On Friday, January 17, 2014, Christian Posta <ch...@gmail.com>
wrote:
> well, karaf does ship with a console, the command-line shell.
>
> but i think we're talking about the web console.
>
> in 2.3.3, i don't see a webconsole shipped in the distro:
>
> http://pastebin.com/zepcUHMX
>
> in 3.0.0 i don't either:
>
> http://pastebin.com/cfV3yG0Z
>
>
> On Fri, Jan 17, 2014 at 3:19 PM, Hadrian Zbarcea <hz...@gmail.com>
> wrote:
> > Rob, that's not quite correct. Karaf *ships with a console*, ActiveMQ
> also
> > ships with a console. The issue we are discussing now is the distro
> content,
> > right?
> >
> > Hadrian
> >
> >
> >
> >
> > On 01/17/2014 05:07 PM, Robert Davies wrote:
> >>
> >>
> >> On 17 Jan 2014, at 21:53, James Carman <ja...@carmanconsulting.com>
> wrote:
> >>
> >>> Karaf ships with a console
> >>
> >>
> >> Yes - its not installed by default - which is equivalent to option 1.
> >>
> >>>
> >>> On Friday, January 17, 2014, Robert Davies <ra...@gmail.com>
> wrote:
> >>>
> >>>>
> >>>> On 17 Jan 2014, at 16:33, James Carman
> >>>> <james@carmanconsulting.com<javascript:;>>
> >>>> wrote:
> >>>>
> >>>>> Agreed. My point was that we shouldn't just abandon the console that
> >>>>> comes with ActiveMQ. A messaging "product" should have its own
> >>>>> console, if it is to be taken seriously by potential "customers”.
> >>>>
> >>>>
> >>>> I don’t buy in to that at all - having to hit refresh on the web
> browser
> >>>> in 2014 to see if the message count has increased just doesn’t cut
> it -
> >>>> and it hasn’t for a long time.
> >>>> As has been said before, the argument about shipping a console to
> >>>> compete
> >>>> can be used for a container too - but Karaf doesn’t, it makes it
> >>>> optional -
> >>>> and that’s a valid point of view that’s worth replicating.
> >>>>
> >>>>> Providing an even playing field for consoles shouldn't be ActiveMQ's
> >>>>> primary concern. ActiveMQ should concern itself with providing a
> >>>>> best-of-breed messaging system, which should include a management
> >>>>> console.
> >>>>
> >>>>
> >>>> Or point people to a host of alternatives that would enhance the user
> >>>> experience. What I really don’t understand is that the people who are
> >>>> active committers, and actually fix the security issues as they come
> are
> >>>> all saying get rid of the console and our views are being ignored.
> Its
> >>>> not
> >>>> our core competence, nor should it have to be - we are writing a
> message
> >>>> broker. If you feel strongly about it you are of course more than
> >>>> welcome
> >>>> to help write a new console that can be incorporated at a later date.
> >>>>
> >>>>>
> >>>>> On Fri, Jan 17, 2014 at 11:27 AM, Hadrian Zbarcea
> >>>>> <hzbarcea@gmail.com<javascript:;>>
> >>>>
> >>>> wrote:
> >>>>>>
> >>>>>> James,
> >>>>>>
> >>>>>> 5. Is just business as usual, why should it be part of the poll?
> Users
> >>>>
> >>>> raise
> >>>>>>
> >>>>>> an issue, it gets fixed.
> >>>>>>
> >>>>>> My $0.02,
> >>>>>> Hadrian
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 01/17/2014 11:25 AM, James Carman wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> 1. -1
> >>>>>>> 2. -1
> >>>>>>> 3. -1
> >>>>>>> 4. +1
> >>>>>>> 5. Resurrect the "old" console and bring it up-to-date, fixing any
> >>>>>>> outstanding bugs - +1
> >>>>>>>
> >>>>>>>
> >>>>>>> On Fri, Jan 17, 2014 at 8:33 AM, Robert Davies
> >>>>>>> <rajdavies@gmail.com<javascript:;>
> --
> Christian Posta
> http://www.christianposta.com/blog
> twitter: @christianposta
>
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Christian Posta <ch...@gmail.com>.
well, karaf does ship with a console, the command-line shell.
but i think we're talking about the web console.
in 2.3.3, i don't see a webconsole shipped in the distro:
http://pastebin.com/zepcUHMX
in 3.0.0 i don't either:
http://pastebin.com/cfV3yG0Z
On Fri, Jan 17, 2014 at 3:19 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> Rob, that's not quite correct. Karaf *ships with a console*, ActiveMQ also
> ships with a console. The issue we are discussing now is the distro content,
> right?
>
> Hadrian
>
>
>
>
> On 01/17/2014 05:07 PM, Robert Davies wrote:
>>
>>
>> On 17 Jan 2014, at 21:53, James Carman <ja...@carmanconsulting.com> wrote:
>>
>>> Karaf ships with a console
>>
>>
>> Yes - its not installed by default - which is equivalent to option 1.
>>
>>>
>>> On Friday, January 17, 2014, Robert Davies <ra...@gmail.com> wrote:
>>>
>>>>
>>>> On 17 Jan 2014, at 16:33, James Carman
>>>> <james@carmanconsulting.com<javascript:;>>
>>>> wrote:
>>>>
>>>>> Agreed. My point was that we shouldn't just abandon the console that
>>>>> comes with ActiveMQ. A messaging "product" should have its own
>>>>> console, if it is to be taken seriously by potential "customers”.
>>>>
>>>>
>>>> I don’t buy in to that at all - having to hit refresh on the web browser
>>>> in 2014 to see if the message count has increased just doesn’t cut it -
>>>> and it hasn’t for a long time.
>>>> As has been said before, the argument about shipping a console to
>>>> compete
>>>> can be used for a container too - but Karaf doesn’t, it makes it
>>>> optional -
>>>> and that’s a valid point of view that’s worth replicating.
>>>>
>>>>> Providing an even playing field for consoles shouldn't be ActiveMQ's
>>>>> primary concern. ActiveMQ should concern itself with providing a
>>>>> best-of-breed messaging system, which should include a management
>>>>> console.
>>>>
>>>>
>>>> Or point people to a host of alternatives that would enhance the user
>>>> experience. What I really don’t understand is that the people who are
>>>> active committers, and actually fix the security issues as they come are
>>>> all saying get rid of the console and our views are being ignored. Its
>>>> not
>>>> our core competence, nor should it have to be - we are writing a message
>>>> broker. If you feel strongly about it you are of course more than
>>>> welcome
>>>> to help write a new console that can be incorporated at a later date.
>>>>
>>>>>
>>>>> On Fri, Jan 17, 2014 at 11:27 AM, Hadrian Zbarcea
>>>>> <hzbarcea@gmail.com<javascript:;>>
>>>>
>>>> wrote:
>>>>>>
>>>>>> James,
>>>>>>
>>>>>> 5. Is just business as usual, why should it be part of the poll? Users
>>>>
>>>> raise
>>>>>>
>>>>>> an issue, it gets fixed.
>>>>>>
>>>>>> My $0.02,
>>>>>> Hadrian
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 01/17/2014 11:25 AM, James Carman wrote:
>>>>>>>
>>>>>>>
>>>>>>> 1. -1
>>>>>>> 2. -1
>>>>>>> 3. -1
>>>>>>> 4. +1
>>>>>>> 5. Resurrect the "old" console and bring it up-to-date, fixing any
>>>>>>> outstanding bugs - +1
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 17, 2014 at 8:33 AM, Robert Davies
>>>>>>> <rajdavies@gmail.com<javascript:;>
>>>>>
>>>>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> I want to take a straw poll to see where everyone stands, because
>>>>
>>>> opinion
>>>>>>>>
>>>>>>>> has varied, mine included. Straw polls can be a useful tool to move
>>>>
>>>> towards
>>>>>>>>
>>>>>>>> consensus. This isn’t a formal vote, but to reduce the noise, can we
>>>>
>>>> keep it
>>>>>>>>
>>>>>>>> to binding votes only ?
>>>>>>>>
>>>>>>>>
>>>>>>>> 1. Have one distribution with no default console, but make it easy
>>>>>>>> to
>>>>>>>> deploy a console on demand (the original console - or 3rd party
>>>>>>>> ones).
>>>>>>>> 2. Have two separate distributions, one with no console - and have
>>>>>>>> a
>>>>>>>> second distribution with the original console
>>>>>>>> 3. One distribution, with hawtio as the console - ActiveMQ branded.
>>>>>>>> 4. One distribution, but uses the original ActiveMQ console only.
>>>>>>>>
>>>>>>>> Here’s my vote:
>>>>>>>>
>>>>>>>> [1]. +1
>>>>>>>> [2] 0
>>>>>>>> [3] 0
>>>>>>>> [4] -1
>>>>>>>>
>>>>>>>> thanks,
>>>>>>>>
>>>>>>>> Rob
>>>>>>>>
>>>>>>
>>>>
>>>> Rob Davies
>>>> ————————
>>>> Red Hat, Inc
>>>> http://hawt.io - #dontcha
>>>> Twitter: rajdavies
>>>> Blog: http://rajdavies.blogspot.com
>>>> ActiveMQ in Action: http://www.manning.com/snyder/
>>>>
>>>>
>>
>> Rob Davies
>> ————————
>> Red Hat, Inc
>> http://hawt.io - #dontcha
>> Twitter: rajdavies
>> Blog: http://rajdavies.blogspot.com
>> ActiveMQ in Action: http://www.manning.com/snyder/
>>
>>
>
--
Christian Posta
http://www.christianposta.com/blog
twitter: @christianposta
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Rob, that's not quite correct. Karaf *ships with a console*, ActiveMQ
also ships with a console. The issue we are discussing now is the distro
content, right?
Hadrian
On 01/17/2014 05:07 PM, Robert Davies wrote:
>
> On 17 Jan 2014, at 21:53, James Carman <ja...@carmanconsulting.com> wrote:
>
>> Karaf ships with a console
>
> Yes - its not installed by default - which is equivalent to option 1.
>
>>
>> On Friday, January 17, 2014, Robert Davies <ra...@gmail.com> wrote:
>>
>>>
>>> On 17 Jan 2014, at 16:33, James Carman <james@carmanconsulting.com<javascript:;>>
>>> wrote:
>>>
>>>> Agreed. My point was that we shouldn't just abandon the console that
>>>> comes with ActiveMQ. A messaging "product" should have its own
>>>> console, if it is to be taken seriously by potential "customers”.
>>>
>>> I don’t buy in to that at all - having to hit refresh on the web browser
>>> in 2014 to see if the message count has increased just doesn’t cut it -
>>> and it hasn’t for a long time.
>>> As has been said before, the argument about shipping a console to compete
>>> can be used for a container too - but Karaf doesn’t, it makes it optional -
>>> and that’s a valid point of view that’s worth replicating.
>>>
>>>> Providing an even playing field for consoles shouldn't be ActiveMQ's
>>>> primary concern. ActiveMQ should concern itself with providing a
>>>> best-of-breed messaging system, which should include a management
>>>> console.
>>>
>>> Or point people to a host of alternatives that would enhance the user
>>> experience. What I really don’t understand is that the people who are
>>> active committers, and actually fix the security issues as they come are
>>> all saying get rid of the console and our views are being ignored. Its not
>>> our core competence, nor should it have to be - we are writing a message
>>> broker. If you feel strongly about it you are of course more than welcome
>>> to help write a new console that can be incorporated at a later date.
>>>
>>>>
>>>> On Fri, Jan 17, 2014 at 11:27 AM, Hadrian Zbarcea <hzbarcea@gmail.com<javascript:;>>
>>> wrote:
>>>>> James,
>>>>>
>>>>> 5. Is just business as usual, why should it be part of the poll? Users
>>> raise
>>>>> an issue, it gets fixed.
>>>>>
>>>>> My $0.02,
>>>>> Hadrian
>>>>>
>>>>>
>>>>>
>>>>> On 01/17/2014 11:25 AM, James Carman wrote:
>>>>>>
>>>>>> 1. -1
>>>>>> 2. -1
>>>>>> 3. -1
>>>>>> 4. +1
>>>>>> 5. Resurrect the "old" console and bring it up-to-date, fixing any
>>>>>> outstanding bugs - +1
>>>>>>
>>>>>>
>>>>>> On Fri, Jan 17, 2014 at 8:33 AM, Robert Davies <rajdavies@gmail.com<javascript:;>
>>>>
>>>>>> wrote:
>>>>>>>
>>>>>>> I want to take a straw poll to see where everyone stands, because
>>> opinion
>>>>>>> has varied, mine included. Straw polls can be a useful tool to move
>>> towards
>>>>>>> consensus. This isn’t a formal vote, but to reduce the noise, can we
>>> keep it
>>>>>>> to binding votes only ?
>>>>>>>
>>>>>>>
>>>>>>> 1. Have one distribution with no default console, but make it easy to
>>>>>>> deploy a console on demand (the original console - or 3rd party ones).
>>>>>>> 2. Have two separate distributions, one with no console - and have a
>>>>>>> second distribution with the original console
>>>>>>> 3. One distribution, with hawtio as the console - ActiveMQ branded.
>>>>>>> 4. One distribution, but uses the original ActiveMQ console only.
>>>>>>>
>>>>>>> Here’s my vote:
>>>>>>>
>>>>>>> [1]. +1
>>>>>>> [2] 0
>>>>>>> [3] 0
>>>>>>> [4] -1
>>>>>>>
>>>>>>> thanks,
>>>>>>>
>>>>>>> Rob
>>>>>>>
>>>>>
>>>
>>> Rob Davies
>>> ————————
>>> Red Hat, Inc
>>> http://hawt.io - #dontcha
>>> Twitter: rajdavies
>>> Blog: http://rajdavies.blogspot.com
>>> ActiveMQ in Action: http://www.manning.com/snyder/
>>>
>>>
>
> Rob Davies
> ————————
> Red Hat, Inc
> http://hawt.io - #dontcha
> Twitter: rajdavies
> Blog: http://rajdavies.blogspot.com
> ActiveMQ in Action: http://www.manning.com/snyder/
>
>
Re: [POLL] - Remove the old ActiveMQ Console
Posted by James Carman <ja...@carmanconsulting.com>.
It has the tui on by default
On Friday, January 17, 2014, Robert Davies <ra...@gmail.com> wrote:
>
> On 17 Jan 2014, at 21:53, James Carman <james@carmanconsulting.com<javascript:;>>
> wrote:
>
> > Karaf ships with a console
>
> Yes - its not installed by default - which is equivalent to option 1.
>
> >
> > On Friday, January 17, 2014, Robert Davies <rajdavies@gmail.com<javascript:;>>
> wrote:
> >
> >>
> >> On 17 Jan 2014, at 16:33, James Carman <james@carmanconsulting.com<javascript:;>
> <javascript:;>>
> >> wrote:
> >>
> >>> Agreed. My point was that we shouldn't just abandon the console that
> >>> comes with ActiveMQ. A messaging "product" should have its own
> >>> console, if it is to be taken seriously by potential "customers”.
> >>
> >> I don’t buy in to that at all - having to hit refresh on the web browser
> >> in 2014 to see if the message count has increased just doesn’t cut it -
> >> and it hasn’t for a long time.
> >> As has been said before, the argument about shipping a console to
> compete
> >> can be used for a container too - but Karaf doesn’t, it makes it
> optional -
> >> and that’s a valid point of view that’s worth replicating.
> >>
> >>> Providing an even playing field for consoles shouldn't be ActiveMQ's
> >>> primary concern. ActiveMQ should concern itself with providing a
> >>> best-of-breed messaging system, which should include a management
> >>> console.
> >>
> >> Or point people to a host of alternatives that would enhance the user
> >> experience. What I really don’t understand is that the people who are
> >> active committers, and actually fix the security issues as they come are
> >> all saying get rid of the console and our views are being ignored. Its
> not
> >> our core competence, nor should it have to be - we are writing a message
> >> broker. If you feel strongly about it you are of course more than
> welcome
> >> to help write a new console that can be incorporated at a later date.
> >>
> >>>
> >>> On Fri, Jan 17, 2014 at 11:27 AM, Hadrian Zbarcea <hzbarcea@gmail.com<javascript:;>
> <javascript:;>>
> >> wrote:
> >>>> James,
> >>>>
> >>>> 5. Is just business as usual, why should it be part of the poll? Users
> >> raise
> >>>> an issue, it gets fixed.
> >>>>
> >>>> My $0.02,
> >>>> Hadrian
> >>>>
> >>>>
> >>>>
> >>>> On 01/17/2014 11:25 AM, James Carman wrote:
> >>>>>
> >>>>> 1. -1
> >>>>> 2. -1
> >>>>> 3. -1
> >>>>> 4. +1
> >>>>> 5. Resurrect the "old" console and bring it up-to-date, fixing any
> >>>>> outstanding bugs - +1
> >>>>>
> >>>>>
> >>>>> On Fri, Jan 17, 2014 at 8:33 AM, Robert Davies <rajdavies@gmail.com<javascript:;>
> <javascript:;>
> >>>
> >>>>> wrote:
> >>>>>>
> >>>>>> I want to take a straw poll to see where everyone stands, because
> >> opinion
> >>>>>> has varied, mine included. Straw polls can be a useful tool to move
> >> towards
> >>>>>> consensus. This isn’t a formal vote, but to reduce the noise, can we
> >> keep it
> >>>>>> to binding votes only ?
> >>>>>>
> >>>>>>
> >>>>>> 1. Have one distribution with no default console, but make it easy
> to
> >>>>>> deploy a console on demand (the original console - or 3rd party
> ones).
> >>>>>> 2. Have two separate distributions, one with no console - and have
> a
> >>>>>> second distribution with the original console
> >>>>>> 3. One distribution, with hawtio as the console - ActiveMQ branded.
> >>>>>> 4. One distribution, but uses the original ActiveMQ console only.
> >>>>>>
> >>>>>> Here’s my vote:
> >>>>>>
> >>>>>> [1]. +1
> >>>>>> [2] 0
> >>>>>> [3] 0
> >>>>>> [4] -1
> >>>>>>
> >>>>>> thanks,
> >>>>>>
> >>>>>> Rob
> >>>>>>
> >>>>
> >>
> >> Rob Davies
> >> ————————
> >> Red Hat, Inc
> >> http://hawt.io - #dontcha
> >> Twitter: rajdavies
> >> Blog: http://rajdavies.blogspot.com
> >> ActiveMQ in Action: http://www.manning.com/snyder/
> >>
> >>
>
> Rob Davies
> ————————
> Red Hat, Inc
> http://hawt.io - #dontcha
> Twitter: rajdavies
> Blog: http://rajdavies.blogspot.com
> ActiveMQ in Action: http://www.manning.com/snyder/
>
>
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Robert Davies <ra...@gmail.com>.
On 17 Jan 2014, at 21:53, James Carman <ja...@carmanconsulting.com> wrote:
> Karaf ships with a console
Yes - its not installed by default - which is equivalent to option 1.
>
> On Friday, January 17, 2014, Robert Davies <ra...@gmail.com> wrote:
>
>>
>> On 17 Jan 2014, at 16:33, James Carman <james@carmanconsulting.com<javascript:;>>
>> wrote:
>>
>>> Agreed. My point was that we shouldn't just abandon the console that
>>> comes with ActiveMQ. A messaging "product" should have its own
>>> console, if it is to be taken seriously by potential "customers”.
>>
>> I don’t buy in to that at all - having to hit refresh on the web browser
>> in 2014 to see if the message count has increased just doesn’t cut it -
>> and it hasn’t for a long time.
>> As has been said before, the argument about shipping a console to compete
>> can be used for a container too - but Karaf doesn’t, it makes it optional -
>> and that’s a valid point of view that’s worth replicating.
>>
>>> Providing an even playing field for consoles shouldn't be ActiveMQ's
>>> primary concern. ActiveMQ should concern itself with providing a
>>> best-of-breed messaging system, which should include a management
>>> console.
>>
>> Or point people to a host of alternatives that would enhance the user
>> experience. What I really don’t understand is that the people who are
>> active committers, and actually fix the security issues as they come are
>> all saying get rid of the console and our views are being ignored. Its not
>> our core competence, nor should it have to be - we are writing a message
>> broker. If you feel strongly about it you are of course more than welcome
>> to help write a new console that can be incorporated at a later date.
>>
>>>
>>> On Fri, Jan 17, 2014 at 11:27 AM, Hadrian Zbarcea <hzbarcea@gmail.com<javascript:;>>
>> wrote:
>>>> James,
>>>>
>>>> 5. Is just business as usual, why should it be part of the poll? Users
>> raise
>>>> an issue, it gets fixed.
>>>>
>>>> My $0.02,
>>>> Hadrian
>>>>
>>>>
>>>>
>>>> On 01/17/2014 11:25 AM, James Carman wrote:
>>>>>
>>>>> 1. -1
>>>>> 2. -1
>>>>> 3. -1
>>>>> 4. +1
>>>>> 5. Resurrect the "old" console and bring it up-to-date, fixing any
>>>>> outstanding bugs - +1
>>>>>
>>>>>
>>>>> On Fri, Jan 17, 2014 at 8:33 AM, Robert Davies <rajdavies@gmail.com<javascript:;>
>>>
>>>>> wrote:
>>>>>>
>>>>>> I want to take a straw poll to see where everyone stands, because
>> opinion
>>>>>> has varied, mine included. Straw polls can be a useful tool to move
>> towards
>>>>>> consensus. This isn’t a formal vote, but to reduce the noise, can we
>> keep it
>>>>>> to binding votes only ?
>>>>>>
>>>>>>
>>>>>> 1. Have one distribution with no default console, but make it easy to
>>>>>> deploy a console on demand (the original console - or 3rd party ones).
>>>>>> 2. Have two separate distributions, one with no console - and have a
>>>>>> second distribution with the original console
>>>>>> 3. One distribution, with hawtio as the console - ActiveMQ branded.
>>>>>> 4. One distribution, but uses the original ActiveMQ console only.
>>>>>>
>>>>>> Here’s my vote:
>>>>>>
>>>>>> [1]. +1
>>>>>> [2] 0
>>>>>> [3] 0
>>>>>> [4] -1
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> Rob
>>>>>>
>>>>
>>
>> Rob Davies
>> ————————
>> Red Hat, Inc
>> http://hawt.io - #dontcha
>> Twitter: rajdavies
>> Blog: http://rajdavies.blogspot.com
>> ActiveMQ in Action: http://www.manning.com/snyder/
>>
>>
Rob Davies
————————
Red Hat, Inc
http://hawt.io - #dontcha
Twitter: rajdavies
Blog: http://rajdavies.blogspot.com
ActiveMQ in Action: http://www.manning.com/snyder/
Re: [POLL] - Remove the old ActiveMQ Console
Posted by James Carman <ja...@carmanconsulting.com>.
Karaf ships with a console
On Friday, January 17, 2014, Robert Davies <ra...@gmail.com> wrote:
>
> On 17 Jan 2014, at 16:33, James Carman <james@carmanconsulting.com<javascript:;>>
> wrote:
>
> > Agreed. My point was that we shouldn't just abandon the console that
> > comes with ActiveMQ. A messaging "product" should have its own
> > console, if it is to be taken seriously by potential "customers”.
>
> I don’t buy in to that at all - having to hit refresh on the web browser
> in 2014 to see if the message count has increased just doesn’t cut it -
> and it hasn’t for a long time.
> As has been said before, the argument about shipping a console to compete
> can be used for a container too - but Karaf doesn’t, it makes it optional -
> and that’s a valid point of view that’s worth replicating.
>
> > Providing an even playing field for consoles shouldn't be ActiveMQ's
> > primary concern. ActiveMQ should concern itself with providing a
> > best-of-breed messaging system, which should include a management
> > console.
>
> Or point people to a host of alternatives that would enhance the user
> experience. What I really don’t understand is that the people who are
> active committers, and actually fix the security issues as they come are
> all saying get rid of the console and our views are being ignored. Its not
> our core competence, nor should it have to be - we are writing a message
> broker. If you feel strongly about it you are of course more than welcome
> to help write a new console that can be incorporated at a later date.
>
> >
> > On Fri, Jan 17, 2014 at 11:27 AM, Hadrian Zbarcea <hzbarcea@gmail.com<javascript:;>>
> wrote:
> >> James,
> >>
> >> 5. Is just business as usual, why should it be part of the poll? Users
> raise
> >> an issue, it gets fixed.
> >>
> >> My $0.02,
> >> Hadrian
> >>
> >>
> >>
> >> On 01/17/2014 11:25 AM, James Carman wrote:
> >>>
> >>> 1. -1
> >>> 2. -1
> >>> 3. -1
> >>> 4. +1
> >>> 5. Resurrect the "old" console and bring it up-to-date, fixing any
> >>> outstanding bugs - +1
> >>>
> >>>
> >>> On Fri, Jan 17, 2014 at 8:33 AM, Robert Davies <rajdavies@gmail.com<javascript:;>
> >
> >>> wrote:
> >>>>
> >>>> I want to take a straw poll to see where everyone stands, because
> opinion
> >>>> has varied, mine included. Straw polls can be a useful tool to move
> towards
> >>>> consensus. This isn’t a formal vote, but to reduce the noise, can we
> keep it
> >>>> to binding votes only ?
> >>>>
> >>>>
> >>>> 1. Have one distribution with no default console, but make it easy to
> >>>> deploy a console on demand (the original console - or 3rd party ones).
> >>>> 2. Have two separate distributions, one with no console - and have a
> >>>> second distribution with the original console
> >>>> 3. One distribution, with hawtio as the console - ActiveMQ branded.
> >>>> 4. One distribution, but uses the original ActiveMQ console only.
> >>>>
> >>>> Here’s my vote:
> >>>>
> >>>> [1]. +1
> >>>> [2] 0
> >>>> [3] 0
> >>>> [4] -1
> >>>>
> >>>> thanks,
> >>>>
> >>>> Rob
> >>>>
> >>
>
> Rob Davies
> ————————
> Red Hat, Inc
> http://hawt.io - #dontcha
> Twitter: rajdavies
> Blog: http://rajdavies.blogspot.com
> ActiveMQ in Action: http://www.manning.com/snyder/
>
>
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Robert Davies <ra...@gmail.com>.
On 17 Jan 2014, at 16:33, James Carman <ja...@carmanconsulting.com> wrote:
> Agreed. My point was that we shouldn't just abandon the console that
> comes with ActiveMQ. A messaging "product" should have its own
> console, if it is to be taken seriously by potential "customers”.
I don’t buy in to that at all - having to hit refresh on the web browser in 2014 to see if the message count has increased just doesn’t cut it - and it hasn’t for a long time.
As has been said before, the argument about shipping a console to compete can be used for a container too - but Karaf doesn’t, it makes it optional - and that’s a valid point of view that’s worth replicating.
> Providing an even playing field for consoles shouldn't be ActiveMQ's
> primary concern. ActiveMQ should concern itself with providing a
> best-of-breed messaging system, which should include a management
> console.
Or point people to a host of alternatives that would enhance the user experience. What I really don’t understand is that the people who are active committers, and actually fix the security issues as they come are all saying get rid of the console and our views are being ignored. Its not our core competence, nor should it have to be - we are writing a message broker. If you feel strongly about it you are of course more than welcome to help write a new console that can be incorporated at a later date.
>
> On Fri, Jan 17, 2014 at 11:27 AM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>> James,
>>
>> 5. Is just business as usual, why should it be part of the poll? Users raise
>> an issue, it gets fixed.
>>
>> My $0.02,
>> Hadrian
>>
>>
>>
>> On 01/17/2014 11:25 AM, James Carman wrote:
>>>
>>> 1. -1
>>> 2. -1
>>> 3. -1
>>> 4. +1
>>> 5. Resurrect the "old" console and bring it up-to-date, fixing any
>>> outstanding bugs - +1
>>>
>>>
>>> On Fri, Jan 17, 2014 at 8:33 AM, Robert Davies <ra...@gmail.com>
>>> wrote:
>>>>
>>>> I want to take a straw poll to see where everyone stands, because opinion
>>>> has varied, mine included. Straw polls can be a useful tool to move towards
>>>> consensus. This isn’t a formal vote, but to reduce the noise, can we keep it
>>>> to binding votes only ?
>>>>
>>>>
>>>> 1. Have one distribution with no default console, but make it easy to
>>>> deploy a console on demand (the original console - or 3rd party ones).
>>>> 2. Have two separate distributions, one with no console - and have a
>>>> second distribution with the original console
>>>> 3. One distribution, with hawtio as the console - ActiveMQ branded.
>>>> 4. One distribution, but uses the original ActiveMQ console only.
>>>>
>>>> Here’s my vote:
>>>>
>>>> [1]. +1
>>>> [2] 0
>>>> [3] 0
>>>> [4] -1
>>>>
>>>> thanks,
>>>>
>>>> Rob
>>>>
>>
Rob Davies
————————
Red Hat, Inc
http://hawt.io - #dontcha
Twitter: rajdavies
Blog: http://rajdavies.blogspot.com
ActiveMQ in Action: http://www.manning.com/snyder/
Re: [POLL] - Remove the old ActiveMQ Console
Posted by James Carman <ja...@carmanconsulting.com>.
Agreed. My point was that we shouldn't just abandon the console that
comes with ActiveMQ. A messaging "product" should have its own
console, if it is to be taken seriously by potential "customers".
Providing an even playing field for consoles shouldn't be ActiveMQ's
primary concern. ActiveMQ should concern itself with providing a
best-of-breed messaging system, which should include a management
console.
On Fri, Jan 17, 2014 at 11:27 AM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> James,
>
> 5. Is just business as usual, why should it be part of the poll? Users raise
> an issue, it gets fixed.
>
> My $0.02,
> Hadrian
>
>
>
> On 01/17/2014 11:25 AM, James Carman wrote:
>>
>> 1. -1
>> 2. -1
>> 3. -1
>> 4. +1
>> 5. Resurrect the "old" console and bring it up-to-date, fixing any
>> outstanding bugs - +1
>>
>>
>> On Fri, Jan 17, 2014 at 8:33 AM, Robert Davies <ra...@gmail.com>
>> wrote:
>>>
>>> I want to take a straw poll to see where everyone stands, because opinion
>>> has varied, mine included. Straw polls can be a useful tool to move towards
>>> consensus. This isn’t a formal vote, but to reduce the noise, can we keep it
>>> to binding votes only ?
>>>
>>>
>>> 1. Have one distribution with no default console, but make it easy to
>>> deploy a console on demand (the original console - or 3rd party ones).
>>> 2. Have two separate distributions, one with no console - and have a
>>> second distribution with the original console
>>> 3. One distribution, with hawtio as the console - ActiveMQ branded.
>>> 4. One distribution, but uses the original ActiveMQ console only.
>>>
>>> Here’s my vote:
>>>
>>> [1]. +1
>>> [2] 0
>>> [3] 0
>>> [4] -1
>>>
>>> thanks,
>>>
>>> Rob
>>>
>
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Hadrian Zbarcea <hz...@gmail.com>.
James,
5. Is just business as usual, why should it be part of the poll? Users
raise an issue, it gets fixed.
My $0.02,
Hadrian
On 01/17/2014 11:25 AM, James Carman wrote:
> 1. -1
> 2. -1
> 3. -1
> 4. +1
> 5. Resurrect the "old" console and bring it up-to-date, fixing any
> outstanding bugs - +1
>
>
> On Fri, Jan 17, 2014 at 8:33 AM, Robert Davies <ra...@gmail.com> wrote:
>> I want to take a straw poll to see where everyone stands, because opinion has varied, mine included. Straw polls can be a useful tool to move towards consensus. This isn’t a formal vote, but to reduce the noise, can we keep it to binding votes only ?
>>
>>
>> 1. Have one distribution with no default console, but make it easy to deploy a console on demand (the original console - or 3rd party ones).
>> 2. Have two separate distributions, one with no console - and have a second distribution with the original console
>> 3. One distribution, with hawtio as the console - ActiveMQ branded.
>> 4. One distribution, but uses the original ActiveMQ console only.
>>
>> Here’s my vote:
>>
>> [1]. +1
>> [2] 0
>> [3] 0
>> [4] -1
>>
>> thanks,
>>
>> Rob
>>
Re: [POLL] - Remove the old ActiveMQ Console
Posted by James Carman <ja...@carmanconsulting.com>.
1. -1
2. -1
3. -1
4. +1
5. Resurrect the "old" console and bring it up-to-date, fixing any
outstanding bugs - +1
On Fri, Jan 17, 2014 at 8:33 AM, Robert Davies <ra...@gmail.com> wrote:
> I want to take a straw poll to see where everyone stands, because opinion has varied, mine included. Straw polls can be a useful tool to move towards consensus. This isn’t a formal vote, but to reduce the noise, can we keep it to binding votes only ?
>
>
> 1. Have one distribution with no default console, but make it easy to deploy a console on demand (the original console - or 3rd party ones).
> 2. Have two separate distributions, one with no console - and have a second distribution with the original console
> 3. One distribution, with hawtio as the console - ActiveMQ branded.
> 4. One distribution, but uses the original ActiveMQ console only.
>
> Here’s my vote:
>
> [1]. +1
> [2] 0
> [3] 0
> [4] -1
>
> thanks,
>
> Rob
>
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Robert Davies <ra...@gmail.com>.
On 17 Jan 2014, at 16:18, James Carman <ja...@carmanconsulting.com> wrote:
> Can we get a rundown of the issues with the current console? I don't
> really see a lot of traffic on here complaining about it. Nobody has
> really touched it in a long time, right? So, why not get some folks
> who are interested in it to work on it? I'd be willing to help with
> it.
There are about 21 open issues in jira - but that’s not the problem. The problem is ithe console is more than 5 years out of date and needs to be completely rewritten from scratch.
As always, contributions always welcome.
>
>
> On Fri, Jan 17, 2014 at 8:33 AM, Robert Davies <ra...@gmail.com> wrote:
>> I want to take a straw poll to see where everyone stands, because opinion has varied, mine included. Straw polls can be a useful tool to move towards consensus. This isn’t a formal vote, but to reduce the noise, can we keep it to binding votes only ?
>>
>>
>> 1. Have one distribution with no default console, but make it easy to deploy a console on demand (the original console - or 3rd party ones).
>> 2. Have two separate distributions, one with no console - and have a second distribution with the original console
>> 3. One distribution, with hawtio as the console - ActiveMQ branded.
>> 4. One distribution, but uses the original ActiveMQ console only.
>>
>> Here’s my vote:
>>
>> [1]. +1
>> [2] 0
>> [3] 0
>> [4] -1
>>
>> thanks,
>>
>> Rob
>>
Rob Davies
————————
Red Hat, Inc
http://hawt.io - #dontcha
Twitter: rajdavies
Blog: http://rajdavies.blogspot.com
ActiveMQ in Action: http://www.manning.com/snyder/
Re: [POLL] - Remove the old ActiveMQ Console
Posted by James Carman <ja...@carmanconsulting.com>.
Can we get a rundown of the issues with the current console? I don't
really see a lot of traffic on here complaining about it. Nobody has
really touched it in a long time, right? So, why not get some folks
who are interested in it to work on it? I'd be willing to help with
it.
On Fri, Jan 17, 2014 at 8:33 AM, Robert Davies <ra...@gmail.com> wrote:
> I want to take a straw poll to see where everyone stands, because opinion has varied, mine included. Straw polls can be a useful tool to move towards consensus. This isn’t a formal vote, but to reduce the noise, can we keep it to binding votes only ?
>
>
> 1. Have one distribution with no default console, but make it easy to deploy a console on demand (the original console - or 3rd party ones).
> 2. Have two separate distributions, one with no console - and have a second distribution with the original console
> 3. One distribution, with hawtio as the console - ActiveMQ branded.
> 4. One distribution, but uses the original ActiveMQ console only.
>
> Here’s my vote:
>
> [1]. +1
> [2] 0
> [3] 0
> [4] -1
>
> thanks,
>
> Rob
>
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Gary Tully <ga...@gmail.com>.
[1] 0
[2] -1
[3] +1
[4] -1
On 17 January 2014 13:33, Robert Davies <ra...@gmail.com> wrote:
> I want to take a straw poll to see where everyone stands, because opinion has varied, mine included. Straw polls can be a useful tool to move towards consensus. This isn’t a formal vote, but to reduce the noise, can we keep it to binding votes only ?
>
>
> 1. Have one distribution with no default console, but make it easy to deploy a console on demand (the original console - or 3rd party ones).
> 2. Have two separate distributions, one with no console - and have a second distribution with the original console
> 3. One distribution, with hawtio as the console - ActiveMQ branded.
> 4. One distribution, but uses the original ActiveMQ console only.
>
> Here’s my vote:
>
> [1]. +1
> [2] 0
> [3] 0
> [4] -1
>
> thanks,
>
> Rob
>
--
http://redhat.com
http://blog.garytully.com
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Jon Anstey <ja...@gmail.com>.
On Tue, Jan 21, 2014 at 4:00 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> On Jan 21, 2014, at 1:15 PM, Jon Anstey <ja...@gmail.com> wrote:
>
> > So even skinning hawtio to be ASF compliant is not enough now??? Telling
> > the hawtio devs to give all activemq related code over is WAY overzeolous
> > IMHO. There are no ASF rules that say this must be done.
> >
> > I consider working with other open source communities to be a sign of a
> > healthy community, not the other way around as you put it. Apache
> > communities ARE NOT and SHOULD NOT be silos.
>
> I COMPLETELY support working with other open source communities.
That is great. So you want to work with the hawtio community on this. It
just sounded like you didn't from the previous emails. Asking to move code
from another project is not a good way to work with them ;-)
> I’m also completely in support for working with other closed source
> communities. If other communities have needs from ActiveMQ such as new
> API’s, new functionality, etc… I’m more than happy to work with them to
> make sure what we provide can meet their needs. Better yet, I’d be more
> than happy to work with them to help them become committers and PMC members
> here so THEY can make sure ActiveMQ will meet their needs.
>
> I’m also quite willing to provide fair and impartial links from the “third
> party stuff” page on our website to the other communities. I’m willing to
> say “what we provide is pretty basic to get you started, there is likely
> better stuff available elsewhere, see that page”.
>
> I’m quite willing to use other open source projects to build solutions
> within Apache and even push fixes and stuff back PROVIDING the
> functionality directly related to the Apache project is part of the Apache
> project. As an example: CXF builds upon Spring. It used to heavily build
> upon Spring, it’s quite a bit more reduced now. Spring was a good
> framework to chose to build upon. However, the “Web Services” stuff is
> all in CXF. The Namespace handlers to extend Spring are all in CXF. The
> beans to configure are all in CXF.
>
> What I’m NOT OK with is handing over the development of the primary user
> experience of an Apache project to a third party and then “endorsing” that
> as the official way to do things by shipping it from Apache. Note: I’m OK
> with handing it over and then NOT shipping/endorsing anything related to
> that kind of user experience in Apache providing the PMC reaches a
> consensus that that is OK. In other words, no console is better than
> giving that up. However, PMC would need to agree that completely dropping
> the console is the best option for the users.
>
That is only your opinion though right? If hawtio is branded/skinned to
meet ASF requirements why can't it be included?
>
> As a USER, the current console, while basic, not HTML5, etc… is “adequate”
> for basic usage. Yes, hawt.io is faster, cleaner, sexier, etc… But the
> console works for many of the basic needs. I would personally prefer it
> over nothing. The fact that you’ve had a couple people ask “what can we
> do to help make it better?” means this community has a means of attracting
> additional people. It surprises me a bit that people aren’t jumping on
> that.
>
No one is jumping on it probably (my opinion here) because discussion +
effort has already been put in since this past summer to move to a new
console so why invest more on the old console.
Haven't counted the poll results so not sure if most want hawtio to stay or
not... just stating my personal opinion here that I think its the best way
to go. I'm +0 on option [1] too if folks really don't like the hawtio
option.
>
> Dan
>
>
>
> >
> > I'm +1 on option [3] BTW (not a binding vote).
> >
> >
> > On Tue, Jan 21, 2014 at 2:06 PM, Daniel Kulp <dk...@apache.org> wrote:
> >
> >>
> >> On Jan 21, 2014, at 12:07 PM, Gary Tully <ga...@gmail.com> wrote:
> >>
> >>> On 21 January 2014 16:30, Daniel Kulp <dk...@apache.org> wrote:
> >>>>
> >>>> 2) All the ActiveMQ related code needs to be moved into the ActiveMQ
> >> project. If someone is using ActiveMQ and wants to contribute changes
> to
> >> how the console looks or displays items or such, they should be making
> >> contributions to ActiveMQ, not some external community (open source,
> free,
> >> or otherwise). The hawt.io “framework” of libraries and such can
> remain
> >> outside, but the ActiveMQ specific portions needs to be part of this
> >> community. If it’s going to be the visible frontend of this project,
> we
> >> need to make sure it drives the developer willing to contribute
> >> enhancements into ActiveMQ.
> >>>>
> >>> This is putting the cart before the horse!
> >>> If we need some changes and if we can't make contributions to hawtio
> >>> (patches, issues etc) we can deal with that by building our own plugin
> >>> or throwing it out or whatever. But why do that now?
> >>
> >> You are basically asking THIS developer community to completely give up
> >> control over how ActiveMQ is presented to the users to a different
> >> community. I personally cannot think of anything much worse for this
> >> community than that. That seems like a horrible idea from an Apache
> >> community standpoint.
> >>
> >> The goals of the Apache communities needs to be to make sure developers
> >> are driven into the Apache communities, not another community.
> >>
> >>> We don't have to own everything that makes activemq better and that
> >>> makes our users experience better, we just have to ensure that it is
> >>> better.
> >>
> >> Making the user experience better is certainly an important aspect of
> the
> >> Apache communities, but the primary focus should be on making sure the
> >> developer community is healthy and we aren’t driving potential
> developers
> >> elsewhere. That NEEDS to be the most important thing at this point,
> >> especially with the current active makeup of this community.
> >>
> >> In particular, since Apache is a 503b charitable non-profit foundation,
> we
> >> cannot be used to promote other communities, particularly those “owned”
> by
> >> a for-profit entity. (open source or otherwise, that’s somewhat
> irrelevant)
> >>
> >> Anyway, as far as *I’m* concerned (but I’m not a member of this PMC,
> just
> >> an interested party), if the hawt.io community is unwilling or unable
> to
> >> support the ActiveMQ community to allow ActiveMQ to maintain control
> over
> >> it’s user experience, then there is no-point engaging with them. It is
> a
> >> waste of time.
> >>
> >> That said, if hawt.io community want to create a full distribution of
> >> ActiveMQ + hawt.io to make life easier for users, they certainly are
> >> welcome to do so as long as it’s not branded ActiveMQ. (and again, not
> >> something to be promoted here)
> >>
> >> Dan
> >>
> >>
> >>> If the hawt.io community is unwilling (or unable) to do the second
> >> part, then, IMO, #3 is a non-starter. If they ARE willing to do that,
> then
> >> great. Lets start figuring out how to get that done. But that’s
> >> something that would need to be discussed on their side first.
> >>>>
> >>>>
> >>>> Dan
> >>>>
> >>>>
> >>>>
> >>>> On Jan 21, 2014, at 10:55 AM, Gary Tully <ga...@gmail.com>
> wrote:
> >>>>
> >>>>> There are a lot of 0s and +1s for option [3] and two -1s
> >>>>>
> >>>>> Let me make a case for it to try and get consensus around it.
> >>>>>
> >>>>> I want to 'replace' the existing web console with something better.
> >>>>> For configuration activemq did not build a dependency injection
> >>>>> framework, we shipped spring.
> >>>>> Learning from that, it does not make sense to me that we build and
> >>>>> maintain a html5 web console.
> >>>>>
> >>>>> An admin/management web front end based over our extensive JMX api
> >>>>> sounds perfect but it needs
> >>>>> a community to evolve and improve it. We (activemq committers) have
> >>>>> proven that we need help in that area.
> >>>>>
> >>>>> Anyone what to change their vote or further expand on the technical
> >>>>> reasons we should not be branding hatwio?
> >>>>>
> >>>>>
> >>>>> On 17 January 2014 13:33, Robert Davies <ra...@gmail.com> wrote:
> >>>>>> I want to take a straw poll to see where everyone stands, because
> >> opinion has varied, mine included. Straw polls can be a useful tool to
> move
> >> towards consensus. This isn’t a formal vote, but to reduce the noise,
> can
> >> we keep it to binding votes only ?
> >>>>>>
> >>>>>>
> >>>>>> 1. Have one distribution with no default console, but make it easy
> to
> >> deploy a console on demand (the original console - or 3rd party ones).
> >>>>>> 2. Have two separate distributions, one with no console - and have
> a
> >> second distribution with the original console
> >>>>>> 3. One distribution, with hawtio as the console - ActiveMQ branded.
> >>>>>> 4. One distribution, but uses the original ActiveMQ console only.
> >>>>>>
> >>>>>> Here’s my vote:
> >>>>>>
> >>>>>> [1]. +1
> >>>>>> [2] 0
> >>>>>> [3] 0
> >>>>>> [4] -1
> >>>>>>
> >>>>>> thanks,
> >>>>>>
> >>>>>> Rob
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> http://redhat.com
> >>>>> http://blog.garytully.com
> >>>>
> >>>> --
> >>>> Daniel Kulp
> >>>> dkulp@apache.org - http://dankulp.com/blog
> >>>> Talend Community Coder - http://coders.talend.com
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> http://redhat.com
> >>> http://blog.garytully.com
> >>
> >> --
> >> Daniel Kulp
> >> dkulp@apache.org - http://dankulp.com/blog
> >> Talend Community Coder - http://coders.talend.com
> >>
> >>
> >
> >
> > --
> > Cheers,
> > Jon
> > ---------------
> > Red Hat, Inc.
> > Email: janstey@redhat.com
> > Web: http://redhat.com
> > Twitter: jon_anstey
> > Blog: http://janstey.blogspot.com
> > Author of Camel in Action: http://manning.com/ibsen
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
--
Cheers,
Jon
---------------
Red Hat, Inc.
Email: janstey@redhat.com
Web: http://redhat.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Daniel Kulp <dk...@apache.org>.
On Jan 21, 2014, at 1:15 PM, Jon Anstey <ja...@gmail.com> wrote:
> So even skinning hawtio to be ASF compliant is not enough now??? Telling
> the hawtio devs to give all activemq related code over is WAY overzeolous
> IMHO. There are no ASF rules that say this must be done.
>
> I consider working with other open source communities to be a sign of a
> healthy community, not the other way around as you put it. Apache
> communities ARE NOT and SHOULD NOT be silos.
I COMPLETELY support working with other open source communities. I’m also completely in support for working with other closed source communities. If other communities have needs from ActiveMQ such as new API’s, new functionality, etc… I’m more than happy to work with them to make sure what we provide can meet their needs. Better yet, I’d be more than happy to work with them to help them become committers and PMC members here so THEY can make sure ActiveMQ will meet their needs.
I’m also quite willing to provide fair and impartial links from the “third party stuff” page on our website to the other communities. I’m willing to say “what we provide is pretty basic to get you started, there is likely better stuff available elsewhere, see that page”.
I’m quite willing to use other open source projects to build solutions within Apache and even push fixes and stuff back PROVIDING the functionality directly related to the Apache project is part of the Apache project. As an example: CXF builds upon Spring. It used to heavily build upon Spring, it’s quite a bit more reduced now. Spring was a good framework to chose to build upon. However, the “Web Services” stuff is all in CXF. The Namespace handlers to extend Spring are all in CXF. The beans to configure are all in CXF.
What I’m NOT OK with is handing over the development of the primary user experience of an Apache project to a third party and then “endorsing” that as the official way to do things by shipping it from Apache. Note: I’m OK with handing it over and then NOT shipping/endorsing anything related to that kind of user experience in Apache providing the PMC reaches a consensus that that is OK. In other words, no console is better than giving that up. However, PMC would need to agree that completely dropping the console is the best option for the users.
As a USER, the current console, while basic, not HTML5, etc… is “adequate” for basic usage. Yes, hawt.io is faster, cleaner, sexier, etc… But the console works for many of the basic needs. I would personally prefer it over nothing. The fact that you’ve had a couple people ask “what can we do to help make it better?” means this community has a means of attracting additional people. It surprises me a bit that people aren’t jumping on that.
Dan
>
> I'm +1 on option [3] BTW (not a binding vote).
>
>
> On Tue, Jan 21, 2014 at 2:06 PM, Daniel Kulp <dk...@apache.org> wrote:
>
>>
>> On Jan 21, 2014, at 12:07 PM, Gary Tully <ga...@gmail.com> wrote:
>>
>>> On 21 January 2014 16:30, Daniel Kulp <dk...@apache.org> wrote:
>>>>
>>>> 2) All the ActiveMQ related code needs to be moved into the ActiveMQ
>> project. If someone is using ActiveMQ and wants to contribute changes to
>> how the console looks or displays items or such, they should be making
>> contributions to ActiveMQ, not some external community (open source, free,
>> or otherwise). The hawt.io “framework” of libraries and such can remain
>> outside, but the ActiveMQ specific portions needs to be part of this
>> community. If it’s going to be the visible frontend of this project, we
>> need to make sure it drives the developer willing to contribute
>> enhancements into ActiveMQ.
>>>>
>>> This is putting the cart before the horse!
>>> If we need some changes and if we can't make contributions to hawtio
>>> (patches, issues etc) we can deal with that by building our own plugin
>>> or throwing it out or whatever. But why do that now?
>>
>> You are basically asking THIS developer community to completely give up
>> control over how ActiveMQ is presented to the users to a different
>> community. I personally cannot think of anything much worse for this
>> community than that. That seems like a horrible idea from an Apache
>> community standpoint.
>>
>> The goals of the Apache communities needs to be to make sure developers
>> are driven into the Apache communities, not another community.
>>
>>> We don't have to own everything that makes activemq better and that
>>> makes our users experience better, we just have to ensure that it is
>>> better.
>>
>> Making the user experience better is certainly an important aspect of the
>> Apache communities, but the primary focus should be on making sure the
>> developer community is healthy and we aren’t driving potential developers
>> elsewhere. That NEEDS to be the most important thing at this point,
>> especially with the current active makeup of this community.
>>
>> In particular, since Apache is a 503b charitable non-profit foundation, we
>> cannot be used to promote other communities, particularly those “owned” by
>> a for-profit entity. (open source or otherwise, that’s somewhat irrelevant)
>>
>> Anyway, as far as *I’m* concerned (but I’m not a member of this PMC, just
>> an interested party), if the hawt.io community is unwilling or unable to
>> support the ActiveMQ community to allow ActiveMQ to maintain control over
>> it’s user experience, then there is no-point engaging with them. It is a
>> waste of time.
>>
>> That said, if hawt.io community want to create a full distribution of
>> ActiveMQ + hawt.io to make life easier for users, they certainly are
>> welcome to do so as long as it’s not branded ActiveMQ. (and again, not
>> something to be promoted here)
>>
>> Dan
>>
>>
>>> If the hawt.io community is unwilling (or unable) to do the second
>> part, then, IMO, #3 is a non-starter. If they ARE willing to do that, then
>> great. Lets start figuring out how to get that done. But that’s
>> something that would need to be discussed on their side first.
>>>>
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>> On Jan 21, 2014, at 10:55 AM, Gary Tully <ga...@gmail.com> wrote:
>>>>
>>>>> There are a lot of 0s and +1s for option [3] and two -1s
>>>>>
>>>>> Let me make a case for it to try and get consensus around it.
>>>>>
>>>>> I want to 'replace' the existing web console with something better.
>>>>> For configuration activemq did not build a dependency injection
>>>>> framework, we shipped spring.
>>>>> Learning from that, it does not make sense to me that we build and
>>>>> maintain a html5 web console.
>>>>>
>>>>> An admin/management web front end based over our extensive JMX api
>>>>> sounds perfect but it needs
>>>>> a community to evolve and improve it. We (activemq committers) have
>>>>> proven that we need help in that area.
>>>>>
>>>>> Anyone what to change their vote or further expand on the technical
>>>>> reasons we should not be branding hatwio?
>>>>>
>>>>>
>>>>> On 17 January 2014 13:33, Robert Davies <ra...@gmail.com> wrote:
>>>>>> I want to take a straw poll to see where everyone stands, because
>> opinion has varied, mine included. Straw polls can be a useful tool to move
>> towards consensus. This isn’t a formal vote, but to reduce the noise, can
>> we keep it to binding votes only ?
>>>>>>
>>>>>>
>>>>>> 1. Have one distribution with no default console, but make it easy to
>> deploy a console on demand (the original console - or 3rd party ones).
>>>>>> 2. Have two separate distributions, one with no console - and have a
>> second distribution with the original console
>>>>>> 3. One distribution, with hawtio as the console - ActiveMQ branded.
>>>>>> 4. One distribution, but uses the original ActiveMQ console only.
>>>>>>
>>>>>> Here’s my vote:
>>>>>>
>>>>>> [1]. +1
>>>>>> [2] 0
>>>>>> [3] 0
>>>>>> [4] -1
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> Rob
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://redhat.com
>>>>> http://blog.garytully.com
>>>>
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org - http://dankulp.com/blog
>>>> Talend Community Coder - http://coders.talend.com
>>>>
>>>
>>>
>>>
>>> --
>>> http://redhat.com
>>> http://blog.garytully.com
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
>
>
> --
> Cheers,
> Jon
> ---------------
> Red Hat, Inc.
> Email: janstey@redhat.com
> Web: http://redhat.com
> Twitter: jon_anstey
> Blog: http://janstey.blogspot.com
> Author of Camel in Action: http://manning.com/ibsen
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Jon Anstey <ja...@gmail.com>.
So even skinning hawtio to be ASF compliant is not enough now??? Telling
the hawtio devs to give all activemq related code over is WAY overzeolous
IMHO. There are no ASF rules that say this must be done.
I consider working with other open source communities to be a sign of a
healthy community, not the other way around as you put it. Apache
communities ARE NOT and SHOULD NOT be silos.
I'm +1 on option [3] BTW (not a binding vote).
On Tue, Jan 21, 2014 at 2:06 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> On Jan 21, 2014, at 12:07 PM, Gary Tully <ga...@gmail.com> wrote:
>
> > On 21 January 2014 16:30, Daniel Kulp <dk...@apache.org> wrote:
> >>
> >> 2) All the ActiveMQ related code needs to be moved into the ActiveMQ
> project. If someone is using ActiveMQ and wants to contribute changes to
> how the console looks or displays items or such, they should be making
> contributions to ActiveMQ, not some external community (open source, free,
> or otherwise). The hawt.io “framework” of libraries and such can remain
> outside, but the ActiveMQ specific portions needs to be part of this
> community. If it’s going to be the visible frontend of this project, we
> need to make sure it drives the developer willing to contribute
> enhancements into ActiveMQ.
> >>
> > This is putting the cart before the horse!
> > If we need some changes and if we can't make contributions to hawtio
> > (patches, issues etc) we can deal with that by building our own plugin
> > or throwing it out or whatever. But why do that now?
>
> You are basically asking THIS developer community to completely give up
> control over how ActiveMQ is presented to the users to a different
> community. I personally cannot think of anything much worse for this
> community than that. That seems like a horrible idea from an Apache
> community standpoint.
>
> The goals of the Apache communities needs to be to make sure developers
> are driven into the Apache communities, not another community.
>
> > We don't have to own everything that makes activemq better and that
> > makes our users experience better, we just have to ensure that it is
> > better.
>
> Making the user experience better is certainly an important aspect of the
> Apache communities, but the primary focus should be on making sure the
> developer community is healthy and we aren’t driving potential developers
> elsewhere. That NEEDS to be the most important thing at this point,
> especially with the current active makeup of this community.
>
> In particular, since Apache is a 503b charitable non-profit foundation, we
> cannot be used to promote other communities, particularly those “owned” by
> a for-profit entity. (open source or otherwise, that’s somewhat irrelevant)
>
> Anyway, as far as *I’m* concerned (but I’m not a member of this PMC, just
> an interested party), if the hawt.io community is unwilling or unable to
> support the ActiveMQ community to allow ActiveMQ to maintain control over
> it’s user experience, then there is no-point engaging with them. It is a
> waste of time.
>
> That said, if hawt.io community want to create a full distribution of
> ActiveMQ + hawt.io to make life easier for users, they certainly are
> welcome to do so as long as it’s not branded ActiveMQ. (and again, not
> something to be promoted here)
>
> Dan
>
>
> > If the hawt.io community is unwilling (or unable) to do the second
> part, then, IMO, #3 is a non-starter. If they ARE willing to do that, then
> great. Lets start figuring out how to get that done. But that’s
> something that would need to be discussed on their side first.
> >>
> >>
> >> Dan
> >>
> >>
> >>
> >> On Jan 21, 2014, at 10:55 AM, Gary Tully <ga...@gmail.com> wrote:
> >>
> >>> There are a lot of 0s and +1s for option [3] and two -1s
> >>>
> >>> Let me make a case for it to try and get consensus around it.
> >>>
> >>> I want to 'replace' the existing web console with something better.
> >>> For configuration activemq did not build a dependency injection
> >>> framework, we shipped spring.
> >>> Learning from that, it does not make sense to me that we build and
> >>> maintain a html5 web console.
> >>>
> >>> An admin/management web front end based over our extensive JMX api
> >>> sounds perfect but it needs
> >>> a community to evolve and improve it. We (activemq committers) have
> >>> proven that we need help in that area.
> >>>
> >>> Anyone what to change their vote or further expand on the technical
> >>> reasons we should not be branding hatwio?
> >>>
> >>>
> >>> On 17 January 2014 13:33, Robert Davies <ra...@gmail.com> wrote:
> >>>> I want to take a straw poll to see where everyone stands, because
> opinion has varied, mine included. Straw polls can be a useful tool to move
> towards consensus. This isn’t a formal vote, but to reduce the noise, can
> we keep it to binding votes only ?
> >>>>
> >>>>
> >>>> 1. Have one distribution with no default console, but make it easy to
> deploy a console on demand (the original console - or 3rd party ones).
> >>>> 2. Have two separate distributions, one with no console - and have a
> second distribution with the original console
> >>>> 3. One distribution, with hawtio as the console - ActiveMQ branded.
> >>>> 4. One distribution, but uses the original ActiveMQ console only.
> >>>>
> >>>> Here’s my vote:
> >>>>
> >>>> [1]. +1
> >>>> [2] 0
> >>>> [3] 0
> >>>> [4] -1
> >>>>
> >>>> thanks,
> >>>>
> >>>> Rob
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> http://redhat.com
> >>> http://blog.garytully.com
> >>
> >> --
> >> Daniel Kulp
> >> dkulp@apache.org - http://dankulp.com/blog
> >> Talend Community Coder - http://coders.talend.com
> >>
> >
> >
> >
> > --
> > http://redhat.com
> > http://blog.garytully.com
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
--
Cheers,
Jon
---------------
Red Hat, Inc.
Email: janstey@redhat.com
Web: http://redhat.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Robert Davies <ra...@gmail.com>.
The poll proved there’s no consensus - and none is likely to be reached - so closing this down and will put forward a new proposal.
On 22 Jan 2014, at 23:12, Hadrian Zbarcea <hz...@gmail.com> wrote:
> Well, not all the PMC is happy. And you know full well that raising an AMQ JIRA issue won't help if the code is somewhere else.
>
> Sounds like the the options we can reach consensus on are #2 and #4. Let's focus on that.
>
> Hadrian
>
>
>
> On 01/22/2014 05:30 PM, Hiram Chirino wrote:
>> I don't really see much of a difference. As long as the PMC is happy
>> with the end product that we produce what's the problem? You don't
>> like the way some UI element works? Then raise an ActiveMQ jira issue.
>> We can follow the normal deficiency resolution processes to fix it.
>> If you think we can't for some reason, I'd like to understand why you
>> think that.
>>
>> Perhaps there some special ASF policy your talking about that I'm not
>> aware of? If so, could you you provide me a pointer to where it's
>> documented?
>>
>>
>> On Wed, Jan 22, 2014 at 4:47 PM, James Carman
>> <ja...@carmanconsulting.com> wrote:
>>> This whole "then we shouldn't use any 3rd party libraries" argument is
>>> getting old, Hiram. You know there's a difference between using a
>>> library behind the scenes and the entire web console itself that the
>>> users interact with directly. Come on, man. Give it up.
>>>
>>>
>>> On Wed, Jan 22, 2014 at 1:48 PM, Hiram Chirino <hi...@hiramchirino.com> wrote:
>>>> On Wed, Jan 22, 2014 at 1:04 PM, Daniel Kulp <dk...@apache.org> wrote:
>>>>> That’s completely BS. If I download “activemq-###.tar.gz” from ActiveMQ’s website and I run the startup scripts and such that are documented in that bundle and I find a problem that directly pertains to ActiveMQ, I COMPLETELY expect to be able to go to ActiveMQ’s JIRA and log an issue. I also completely expect to be able to do a “git clone” of ActiveMQ’s repo, diagnose the problem, and submit a patch back to ActiveMQ.
>>>>>
>>>>
>>>> If this is true then we should not be using ANY 3rd party libs at all.
>>>> Most users cannot tell where the line is between 3rd party libs and
>>>> ActiveMQ's source. The ActiveMQ project is ultimately responsible for
>>>> all functionality shipped (if its 3rd party or not). If it's a 3rd
>>>> party defect then the ActiveMQ project needs to either work around the
>>>> defect, patch the defect in the 3rd party library or work with the 3rd
>>>> party to fix the defect. All 3 approaches are possible with hawtio
>>>> too.
>>
Rob Davies
————————
Red Hat, Inc
http://hawt.io - #dontcha
Twitter: rajdavies
Blog: http://rajdavies.blogspot.com
ActiveMQ in Action: http://www.manning.com/snyder/
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Well, not all the PMC is happy. And you know full well that raising an
AMQ JIRA issue won't help if the code is somewhere else.
Sounds like the the options we can reach consensus on are #2 and #4.
Let's focus on that.
Hadrian
On 01/22/2014 05:30 PM, Hiram Chirino wrote:
> I don't really see much of a difference. As long as the PMC is happy
> with the end product that we produce what's the problem? You don't
> like the way some UI element works? Then raise an ActiveMQ jira issue.
> We can follow the normal deficiency resolution processes to fix it.
> If you think we can't for some reason, I'd like to understand why you
> think that.
>
> Perhaps there some special ASF policy your talking about that I'm not
> aware of? If so, could you you provide me a pointer to where it's
> documented?
>
>
> On Wed, Jan 22, 2014 at 4:47 PM, James Carman
> <ja...@carmanconsulting.com> wrote:
>> This whole "then we shouldn't use any 3rd party libraries" argument is
>> getting old, Hiram. You know there's a difference between using a
>> library behind the scenes and the entire web console itself that the
>> users interact with directly. Come on, man. Give it up.
>>
>>
>> On Wed, Jan 22, 2014 at 1:48 PM, Hiram Chirino <hi...@hiramchirino.com> wrote:
>>> On Wed, Jan 22, 2014 at 1:04 PM, Daniel Kulp <dk...@apache.org> wrote:
>>>> That’s completely BS. If I download “activemq-###.tar.gz” from ActiveMQ’s website and I run the startup scripts and such that are documented in that bundle and I find a problem that directly pertains to ActiveMQ, I COMPLETELY expect to be able to go to ActiveMQ’s JIRA and log an issue. I also completely expect to be able to do a “git clone” of ActiveMQ’s repo, diagnose the problem, and submit a patch back to ActiveMQ.
>>>>
>>>
>>> If this is true then we should not be using ANY 3rd party libs at all.
>>> Most users cannot tell where the line is between 3rd party libs and
>>> ActiveMQ's source. The ActiveMQ project is ultimately responsible for
>>> all functionality shipped (if its 3rd party or not). If it's a 3rd
>>> party defect then the ActiveMQ project needs to either work around the
>>> defect, patch the defect in the 3rd party library or work with the 3rd
>>> party to fix the defect. All 3 approaches are possible with hawtio
>>> too.
>
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Hiram Chirino <hi...@hiramchirino.com>.
I don't really see much of a difference. As long as the PMC is happy
with the end product that we produce what's the problem? You don't
like the way some UI element works? Then raise an ActiveMQ jira issue.
We can follow the normal deficiency resolution processes to fix it.
If you think we can't for some reason, I'd like to understand why you
think that.
Perhaps there some special ASF policy your talking about that I'm not
aware of? If so, could you you provide me a pointer to where it's
documented?
On Wed, Jan 22, 2014 at 4:47 PM, James Carman
<ja...@carmanconsulting.com> wrote:
> This whole "then we shouldn't use any 3rd party libraries" argument is
> getting old, Hiram. You know there's a difference between using a
> library behind the scenes and the entire web console itself that the
> users interact with directly. Come on, man. Give it up.
>
>
> On Wed, Jan 22, 2014 at 1:48 PM, Hiram Chirino <hi...@hiramchirino.com> wrote:
>> On Wed, Jan 22, 2014 at 1:04 PM, Daniel Kulp <dk...@apache.org> wrote:
>>> That’s completely BS. If I download “activemq-###.tar.gz” from ActiveMQ’s website and I run the startup scripts and such that are documented in that bundle and I find a problem that directly pertains to ActiveMQ, I COMPLETELY expect to be able to go to ActiveMQ’s JIRA and log an issue. I also completely expect to be able to do a “git clone” of ActiveMQ’s repo, diagnose the problem, and submit a patch back to ActiveMQ.
>>>
>>
>> If this is true then we should not be using ANY 3rd party libs at all.
>> Most users cannot tell where the line is between 3rd party libs and
>> ActiveMQ's source. The ActiveMQ project is ultimately responsible for
>> all functionality shipped (if its 3rd party or not). If it's a 3rd
>> party defect then the ActiveMQ project needs to either work around the
>> defect, patch the defect in the 3rd party library or work with the 3rd
>> party to fix the defect. All 3 approaches are possible with hawtio
>> too.
--
Hiram Chirino
Engineering | Red Hat, Inc.
hchirino@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Let's get the discussion back on track and try to reach some consensus.
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.
We have users specifically asking to retain the console. We also have
people who have stepped up and volunteered to help enhancing the
existing console. Thus, option #1 is off the table.
This leaves #2 and #4. Out of the two, #4 is the status quo and has more
support. The remaining question is if we want two distros or not?
Cheers,
Hadrian
On 01/22/2014 04:47 PM, James Carman wrote:
> This whole "then we shouldn't use any 3rd party libraries" argument is
> getting old, Hiram. You know there's a difference between using a
> library behind the scenes and the entire web console itself that the
> users interact with directly. Come on, man. Give it up.
>
>
> On Wed, Jan 22, 2014 at 1:48 PM, Hiram Chirino <hi...@hiramchirino.com> wrote:
>> On Wed, Jan 22, 2014 at 1:04 PM, Daniel Kulp <dk...@apache.org> wrote:
>>> That’s completely BS. If I download “activemq-###.tar.gz” from ActiveMQ’s website and I run the startup scripts and such that are documented in that bundle and I find a problem that directly pertains to ActiveMQ, I COMPLETELY expect to be able to go to ActiveMQ’s JIRA and log an issue. I also completely expect to be able to do a “git clone” of ActiveMQ’s repo, diagnose the problem, and submit a patch back to ActiveMQ.
>>>
>>
>> If this is true then we should not be using ANY 3rd party libs at all.
>> Most users cannot tell where the line is between 3rd party libs and
>> ActiveMQ's source. The ActiveMQ project is ultimately responsible for
>> all functionality shipped (if its 3rd party or not). If it's a 3rd
>> party defect then the ActiveMQ project needs to either work around the
>> defect, patch the defect in the 3rd party library or work with the 3rd
>> party to fix the defect. All 3 approaches are possible with hawtio
>> too.
>>
>> --
>> Hiram Chirino
>> Engineering | Red Hat, Inc.
>> hchirino@redhat.com | fusesource.com | redhat.com
>> skype: hiramchirino | twitter: @hiramchirino
Re: [POLL] - Remove the old ActiveMQ Console
Posted by James Carman <ja...@carmanconsulting.com>.
This whole "then we shouldn't use any 3rd party libraries" argument is
getting old, Hiram. You know there's a difference between using a
library behind the scenes and the entire web console itself that the
users interact with directly. Come on, man. Give it up.
On Wed, Jan 22, 2014 at 1:48 PM, Hiram Chirino <hi...@hiramchirino.com> wrote:
> On Wed, Jan 22, 2014 at 1:04 PM, Daniel Kulp <dk...@apache.org> wrote:
>> That’s completely BS. If I download “activemq-###.tar.gz” from ActiveMQ’s website and I run the startup scripts and such that are documented in that bundle and I find a problem that directly pertains to ActiveMQ, I COMPLETELY expect to be able to go to ActiveMQ’s JIRA and log an issue. I also completely expect to be able to do a “git clone” of ActiveMQ’s repo, diagnose the problem, and submit a patch back to ActiveMQ.
>>
>
> If this is true then we should not be using ANY 3rd party libs at all.
> Most users cannot tell where the line is between 3rd party libs and
> ActiveMQ's source. The ActiveMQ project is ultimately responsible for
> all functionality shipped (if its 3rd party or not). If it's a 3rd
> party defect then the ActiveMQ project needs to either work around the
> defect, patch the defect in the 3rd party library or work with the 3rd
> party to fix the defect. All 3 approaches are possible with hawtio
> too.
>
> --
> Hiram Chirino
> Engineering | Red Hat, Inc.
> hchirino@redhat.com | fusesource.com | redhat.com
> skype: hiramchirino | twitter: @hiramchirino
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On Wed, Jan 22, 2014 at 1:04 PM, Daniel Kulp <dk...@apache.org> wrote:
> That’s completely BS. If I download “activemq-###.tar.gz” from ActiveMQ’s website and I run the startup scripts and such that are documented in that bundle and I find a problem that directly pertains to ActiveMQ, I COMPLETELY expect to be able to go to ActiveMQ’s JIRA and log an issue. I also completely expect to be able to do a “git clone” of ActiveMQ’s repo, diagnose the problem, and submit a patch back to ActiveMQ.
>
If this is true then we should not be using ANY 3rd party libs at all.
Most users cannot tell where the line is between 3rd party libs and
ActiveMQ's source. The ActiveMQ project is ultimately responsible for
all functionality shipped (if its 3rd party or not). If it's a 3rd
party defect then the ActiveMQ project needs to either work around the
defect, patch the defect in the 3rd party library or work with the 3rd
party to fix the defect. All 3 approaches are possible with hawtio
too.
--
Hiram Chirino
Engineering | Red Hat, Inc.
hchirino@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Daniel Kulp <dk...@apache.org>.
On Jan 21, 2014, at 5:16 PM, Gary Tully <ga...@gmail.com> wrote:
> inline
>
> On 21 January 2014 17:36, Daniel Kulp <dk...@apache.org> wrote:
>
>> The goals of the Apache communities needs to be to make sure developers are driven into the Apache communities, not another community.
> Any goal that hopes to drive developers is a non starter. Developers
> choose, they are not driven.
That’s completely BS. If I download “activemq-###.tar.gz” from ActiveMQ’s website and I run the startup scripts and such that are documented in that bundle and I find a problem that directly pertains to ActiveMQ, I COMPLETELY expect to be able to go to ActiveMQ’s JIRA and log an issue. I also completely expect to be able to do a “git clone” of ActiveMQ’s repo, diagnose the problem, and submit a patch back to ActiveMQ.
If I’m in the *ActiveMQ* console provided/endorsed by the ActiveMQ community and I see that my message is displaying wrong or the data isn’t displaying correctly or the column sizes aren’t taking things into consideration properly or similar, then I, as a developer, completely expect that I can contribute patches to ActiveMQ to fix that. Again, the download needs to drive developers to ActiveMQ, not an external community. Also, the documentation around how to use what is provided by ActiveMQ needs to be on the ActiveMQ web site. Any errors in that documentation should be handled by the ActiveMQ community. Patches for the documentation should go through ActiveMQ’s process.
Dan
> I am suggesting we make a sensible choice
> that helps our community by giving it a better web ui. hawtio wants to
> have the best activemq web console, we want to ship the best activemq
> console. The stars are aligned. If the alignment falters we address
> that.
>
>>
>>> We don't have to own everything that makes activemq better and that
>>> makes our users experience better, we just have to ensure that it is
>>> better.
>>
>> Making the user experience better is certainly an important aspect of the Apache communities, but the primary focus should be on making sure the developer community is healthy and we aren’t driving potential developers elsewhere. That NEEDS to be the most important thing at this point, especially with the current active makeup of this community.
>>
>> In particular, since Apache is a 503b charitable non-profit foundation, we cannot be used to promote other communities, particularly those “owned” by a for-profit entity. (open source or otherwise, that’s somewhat irrelevant)
>>
>> Anyway, as far as *I’m* concerned (but I’m not a member of this PMC, just an interested party), if the hawt.io community is unwilling or unable to support the ActiveMQ community to allow ActiveMQ to maintain control over it’s user experience, then there is no-point engaging with them. It is a waste of time.
>>
>> That said, if hawt.io community want to create a full distribution of ActiveMQ + hawt.io to make life easier for users, they certainly are welcome to do so as long as it’s not branded ActiveMQ. (and again, not something to be promoted here)
>>
>> Dan
>>
>>
>>> If the hawt.io community is unwilling (or unable) to do the second part, then, IMO, #3 is a non-starter. If they ARE willing to do that, then great. Lets start figuring out how to get that done. But that’s something that would need to be discussed on their side first.
>>>>
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>> On Jan 21, 2014, at 10:55 AM, Gary Tully <ga...@gmail.com> wrote:
>>>>
>>>>> There are a lot of 0s and +1s for option [3] and two -1s
>>>>>
>>>>> Let me make a case for it to try and get consensus around it.
>>>>>
>>>>> I want to 'replace' the existing web console with something better.
>>>>> For configuration activemq did not build a dependency injection
>>>>> framework, we shipped spring.
>>>>> Learning from that, it does not make sense to me that we build and
>>>>> maintain a html5 web console.
>>>>>
>>>>> An admin/management web front end based over our extensive JMX api
>>>>> sounds perfect but it needs
>>>>> a community to evolve and improve it. We (activemq committers) have
>>>>> proven that we need help in that area.
>>>>>
>>>>> Anyone what to change their vote or further expand on the technical
>>>>> reasons we should not be branding hatwio?
>>>>>
>>>>>
>>>>> On 17 January 2014 13:33, Robert Davies <ra...@gmail.com> wrote:
>>>>>> I want to take a straw poll to see where everyone stands, because opinion has varied, mine included. Straw polls can be a useful tool to move towards consensus. This isn’t a formal vote, but to reduce the noise, can we keep it to binding votes only ?
>>>>>>
>>>>>>
>>>>>> 1. Have one distribution with no default console, but make it easy to deploy a console on demand (the original console - or 3rd party ones).
>>>>>> 2. Have two separate distributions, one with no console - and have a second distribution with the original console
>>>>>> 3. One distribution, with hawtio as the console - ActiveMQ branded.
>>>>>> 4. One distribution, but uses the original ActiveMQ console only.
>>>>>>
>>>>>> Here’s my vote:
>>>>>>
>>>>>> [1]. +1
>>>>>> [2] 0
>>>>>> [3] 0
>>>>>> [4] -1
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> Rob
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://redhat.com
>>>>> http://blog.garytully.com
>>>>
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org - http://dankulp.com/blog
>>>> Talend Community Coder - http://coders.talend.com
>>>>
>>>
>>>
>>>
>>> --
>>> http://redhat.com
>>> http://blog.garytully.com
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>
>
>
> --
> http://redhat.com
> http://blog.garytully.com
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [POLL] - Remove the old ActiveMQ Console
Posted by James Carman <ja...@carmanconsulting.com>.
So why didn't you guys work on this console "in-house"?
On Wednesday, January 22, 2014, Dejan Bosanac <de...@nighttale.net> wrote:
> In my opinion, this "control issue" is totally overblown. First of all,
> we're not some newcomers trying to put a malware into the project. We're
> people that are developing this project for the last 5-7 years and are
> trying to position it better for the future, by replacing its most obsolete
> component.
>
> But most importantly, you put it as if Apache releases are totally
> uncontrollable and anybody can sneak into it anything they want. But you
> know well that's not the case, as we use proper releases of other projects
> and all "skinning" is done here. Additionally, every release is voted. So
> there's no chance of any misuse at the release time and once it's released
> it can't be changed. What happens when a project we use loses its track? We
> deal with that at that point (find a replacement, fork and continue
> developing, etc.) and it's the same for Spring, Jetty, HawtIO or any other
> part. So the "risk of losing control" is not valid neither from technical
> nor project image standpoint.
>
> Regards
> --
> Dejan Bosanac
> ----------------------
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> dbosanac@redhat.com <javascript:;>
> Twitter: @dejanb
> Blog: http://sensatic.net
> ActiveMQ in Action: http://www.manning.com/snyder/
>
>
> On Tue, Jan 21, 2014 at 11:16 PM, Gary Tully <ga...@gmail.com> wrote:
>
> > inline
> >
> > On 21 January 2014 17:36, Daniel Kulp <dk...@apache.org> wrote:
> > >
> > > On Jan 21, 2014, at 12:07 PM, Gary Tully <ga...@gmail.com> wrote:
> > >
> > >> On 21 January 2014 16:30, Daniel Kulp <dk...@apache.org> wrote:
> > >>>
> > >>> 2) All the ActiveMQ related code needs to be moved into the ActiveMQ
> > project. If someone is using ActiveMQ and wants to contribute changes
> to
> > how the console looks or displays items or such, they should be making
> > contributions to ActiveMQ, not some external community (open source,
> free,
> > or otherwise). The hawt.io “framework” of libraries and such can
> remain
> > outside, but the ActiveMQ specific portions needs to be part of this
> > community. If it’s going to be the visible frontend of this project, we
> > need to make sure it drives the developer willing to contribute
> > enhancements into ActiveMQ.
> > >>>
> > >> This is putting the cart before the horse!
> > >> If we need some changes and if we can't make contributions to hawtio
> > >> (patches, issues etc) we can deal with that by building our own plugin
> > >> or throwing it out or whatever. But why do that now?
> > >
> > > You are basically asking THIS developer community to completely give up
> > control over how ActiveMQ is presented to the users to a different
> > community. I personally cannot think of anything much worse for this
> > community than that. That seems like a horrible idea from an Apache
> > community standpoint.
> > >
> > That is not what I am asking.
> > How can choosing to adopt a better solution to an open problem be
> > giving up control? We can always change our minds and throw it out if
> > it does not serve our needs. The PMC will always be in control of what
> > is released.
> >
> >
> > > The goals of the Apache communities needs to be to make sure developers
> > are driven into the Apache communities, not another community.
> > Any goal that hopes to drive developers is a non starter. Developers
> > choose, they are not driven. I am suggesting we make a sensible choice
> > that helps our community by giving it a better web ui. hawtio wants to
> > have the best activemq web console, we want to ship the best activemq
> > console. The stars are aligned. If the alignment falters we address
> > that.
> >
> > >
> > >> We don't have to own everything that makes activemq better and that
> > >> makes our users experience better, we just have to ensure that it is
> > >> better.
> > >
> > > Making the user experience better is certainly an important aspect of
> > the Apache communities, but the primary focus should be on making sure
> the
> > developer community is healthy and we aren’t driving potential developers
> > elsewhere. That NEEDS to be the most important thing at this point,
> > especially with the current active makeup of this community.
> > >
> > > In particular, since Apache is a 503b charitable non-profit foundation,
> > we cannot be used to promote other communities, particularly those
> “owned”
> > by a for-profit entity. (open source or otherwise, that’s somewhat
> > irrelevant)
> > >
> > > Anyway, as far as *I’m* concerned (but I’m not a member of this PMC,
> > just an interested party), if the hawt.io community is unwilling or
> > unable to support the ActiveMQ community to allow ActiveMQ to maintain
> > control over it’s user experience, then there is no-point engaging with
> > them. It is a waste of time.
> > >
> > > That said, if hawt.io community want to create a full distribution of
> > ActiveMQ + hawt.io to make life easier for users, they certainly are
> > welcome to do so as long as it’s not branded ActiveMQ. (and again, not
> > something to be promoted here)
> > >
> > > Dan
> > >
> > >
> > >> If the hawt.io
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Dejan Bosanac <de...@nighttale.net>.
In my opinion, this "control issue" is totally overblown. First of all,
we're not some newcomers trying to put a malware into the project. We're
people that are developing this project for the last 5-7 years and are
trying to position it better for the future, by replacing its most obsolete
component.
But most importantly, you put it as if Apache releases are totally
uncontrollable and anybody can sneak into it anything they want. But you
know well that's not the case, as we use proper releases of other projects
and all "skinning" is done here. Additionally, every release is voted. So
there's no chance of any misuse at the release time and once it's released
it can't be changed. What happens when a project we use loses its track? We
deal with that at that point (find a replacement, fork and continue
developing, etc.) and it's the same for Spring, Jetty, HawtIO or any other
part. So the "risk of losing control" is not valid neither from technical
nor project image standpoint.
Regards
--
Dejan Bosanac
----------------------
Red Hat, Inc.
FuseSource is now part of Red Hat
dbosanac@redhat.com
Twitter: @dejanb
Blog: http://sensatic.net
ActiveMQ in Action: http://www.manning.com/snyder/
On Tue, Jan 21, 2014 at 11:16 PM, Gary Tully <ga...@gmail.com> wrote:
> inline
>
> On 21 January 2014 17:36, Daniel Kulp <dk...@apache.org> wrote:
> >
> > On Jan 21, 2014, at 12:07 PM, Gary Tully <ga...@gmail.com> wrote:
> >
> >> On 21 January 2014 16:30, Daniel Kulp <dk...@apache.org> wrote:
> >>>
> >>> 2) All the ActiveMQ related code needs to be moved into the ActiveMQ
> project. If someone is using ActiveMQ and wants to contribute changes to
> how the console looks or displays items or such, they should be making
> contributions to ActiveMQ, not some external community (open source, free,
> or otherwise). The hawt.io “framework” of libraries and such can remain
> outside, but the ActiveMQ specific portions needs to be part of this
> community. If it’s going to be the visible frontend of this project, we
> need to make sure it drives the developer willing to contribute
> enhancements into ActiveMQ.
> >>>
> >> This is putting the cart before the horse!
> >> If we need some changes and if we can't make contributions to hawtio
> >> (patches, issues etc) we can deal with that by building our own plugin
> >> or throwing it out or whatever. But why do that now?
> >
> > You are basically asking THIS developer community to completely give up
> control over how ActiveMQ is presented to the users to a different
> community. I personally cannot think of anything much worse for this
> community than that. That seems like a horrible idea from an Apache
> community standpoint.
> >
> That is not what I am asking.
> How can choosing to adopt a better solution to an open problem be
> giving up control? We can always change our minds and throw it out if
> it does not serve our needs. The PMC will always be in control of what
> is released.
>
>
> > The goals of the Apache communities needs to be to make sure developers
> are driven into the Apache communities, not another community.
> Any goal that hopes to drive developers is a non starter. Developers
> choose, they are not driven. I am suggesting we make a sensible choice
> that helps our community by giving it a better web ui. hawtio wants to
> have the best activemq web console, we want to ship the best activemq
> console. The stars are aligned. If the alignment falters we address
> that.
>
> >
> >> We don't have to own everything that makes activemq better and that
> >> makes our users experience better, we just have to ensure that it is
> >> better.
> >
> > Making the user experience better is certainly an important aspect of
> the Apache communities, but the primary focus should be on making sure the
> developer community is healthy and we aren’t driving potential developers
> elsewhere. That NEEDS to be the most important thing at this point,
> especially with the current active makeup of this community.
> >
> > In particular, since Apache is a 503b charitable non-profit foundation,
> we cannot be used to promote other communities, particularly those “owned”
> by a for-profit entity. (open source or otherwise, that’s somewhat
> irrelevant)
> >
> > Anyway, as far as *I’m* concerned (but I’m not a member of this PMC,
> just an interested party), if the hawt.io community is unwilling or
> unable to support the ActiveMQ community to allow ActiveMQ to maintain
> control over it’s user experience, then there is no-point engaging with
> them. It is a waste of time.
> >
> > That said, if hawt.io community want to create a full distribution of
> ActiveMQ + hawt.io to make life easier for users, they certainly are
> welcome to do so as long as it’s not branded ActiveMQ. (and again, not
> something to be promoted here)
> >
> > Dan
> >
> >
> >> If the hawt.io community is unwilling (or unable) to do the second
> part, then, IMO, #3 is a non-starter. If they ARE willing to do that, then
> great. Lets start figuring out how to get that done. But that’s
> something that would need to be discussed on their side first.
> >>>
> >>>
> >>> Dan
> >>>
> >>>
> >>>
> >>> On Jan 21, 2014, at 10:55 AM, Gary Tully <ga...@gmail.com> wrote:
> >>>
> >>>> There are a lot of 0s and +1s for option [3] and two -1s
> >>>>
> >>>> Let me make a case for it to try and get consensus around it.
> >>>>
> >>>> I want to 'replace' the existing web console with something better.
> >>>> For configuration activemq did not build a dependency injection
> >>>> framework, we shipped spring.
> >>>> Learning from that, it does not make sense to me that we build and
> >>>> maintain a html5 web console.
> >>>>
> >>>> An admin/management web front end based over our extensive JMX api
> >>>> sounds perfect but it needs
> >>>> a community to evolve and improve it. We (activemq committers) have
> >>>> proven that we need help in that area.
> >>>>
> >>>> Anyone what to change their vote or further expand on the technical
> >>>> reasons we should not be branding hatwio?
> >>>>
> >>>>
> >>>> On 17 January 2014 13:33, Robert Davies <ra...@gmail.com> wrote:
> >>>>> I want to take a straw poll to see where everyone stands, because
> opinion has varied, mine included. Straw polls can be a useful tool to move
> towards consensus. This isn’t a formal vote, but to reduce the noise, can
> we keep it to binding votes only ?
> >>>>>
> >>>>>
> >>>>> 1. Have one distribution with no default console, but make it easy
> to deploy a console on demand (the original console - or 3rd party ones).
> >>>>> 2. Have two separate distributions, one with no console - and have
> a second distribution with the original console
> >>>>> 3. One distribution, with hawtio as the console - ActiveMQ branded.
> >>>>> 4. One distribution, but uses the original ActiveMQ console only.
> >>>>>
> >>>>> Here’s my vote:
> >>>>>
> >>>>> [1]. +1
> >>>>> [2] 0
> >>>>> [3] 0
> >>>>> [4] -1
> >>>>>
> >>>>> thanks,
> >>>>>
> >>>>> Rob
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> http://redhat.com
> >>>> http://blog.garytully.com
> >>>
> >>> --
> >>> Daniel Kulp
> >>> dkulp@apache.org - http://dankulp.com/blog
> >>> Talend Community Coder - http://coders.talend.com
> >>>
> >>
> >>
> >>
> >> --
> >> http://redhat.com
> >> http://blog.garytully.com
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
>
>
>
> --
> http://redhat.com
> http://blog.garytully.com
>
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Gary Tully <ga...@gmail.com>.
inline
On 21 January 2014 17:36, Daniel Kulp <dk...@apache.org> wrote:
>
> On Jan 21, 2014, at 12:07 PM, Gary Tully <ga...@gmail.com> wrote:
>
>> On 21 January 2014 16:30, Daniel Kulp <dk...@apache.org> wrote:
>>>
>>> 2) All the ActiveMQ related code needs to be moved into the ActiveMQ project. If someone is using ActiveMQ and wants to contribute changes to how the console looks or displays items or such, they should be making contributions to ActiveMQ, not some external community (open source, free, or otherwise). The hawt.io “framework” of libraries and such can remain outside, but the ActiveMQ specific portions needs to be part of this community. If it’s going to be the visible frontend of this project, we need to make sure it drives the developer willing to contribute enhancements into ActiveMQ.
>>>
>> This is putting the cart before the horse!
>> If we need some changes and if we can't make contributions to hawtio
>> (patches, issues etc) we can deal with that by building our own plugin
>> or throwing it out or whatever. But why do that now?
>
> You are basically asking THIS developer community to completely give up control over how ActiveMQ is presented to the users to a different community. I personally cannot think of anything much worse for this community than that. That seems like a horrible idea from an Apache community standpoint.
>
That is not what I am asking.
How can choosing to adopt a better solution to an open problem be
giving up control? We can always change our minds and throw it out if
it does not serve our needs. The PMC will always be in control of what
is released.
> The goals of the Apache communities needs to be to make sure developers are driven into the Apache communities, not another community.
Any goal that hopes to drive developers is a non starter. Developers
choose, they are not driven. I am suggesting we make a sensible choice
that helps our community by giving it a better web ui. hawtio wants to
have the best activemq web console, we want to ship the best activemq
console. The stars are aligned. If the alignment falters we address
that.
>
>> We don't have to own everything that makes activemq better and that
>> makes our users experience better, we just have to ensure that it is
>> better.
>
> Making the user experience better is certainly an important aspect of the Apache communities, but the primary focus should be on making sure the developer community is healthy and we aren’t driving potential developers elsewhere. That NEEDS to be the most important thing at this point, especially with the current active makeup of this community.
>
> In particular, since Apache is a 503b charitable non-profit foundation, we cannot be used to promote other communities, particularly those “owned” by a for-profit entity. (open source or otherwise, that’s somewhat irrelevant)
>
> Anyway, as far as *I’m* concerned (but I’m not a member of this PMC, just an interested party), if the hawt.io community is unwilling or unable to support the ActiveMQ community to allow ActiveMQ to maintain control over it’s user experience, then there is no-point engaging with them. It is a waste of time.
>
> That said, if hawt.io community want to create a full distribution of ActiveMQ + hawt.io to make life easier for users, they certainly are welcome to do so as long as it’s not branded ActiveMQ. (and again, not something to be promoted here)
>
> Dan
>
>
>> If the hawt.io community is unwilling (or unable) to do the second part, then, IMO, #3 is a non-starter. If they ARE willing to do that, then great. Lets start figuring out how to get that done. But that’s something that would need to be discussed on their side first.
>>>
>>>
>>> Dan
>>>
>>>
>>>
>>> On Jan 21, 2014, at 10:55 AM, Gary Tully <ga...@gmail.com> wrote:
>>>
>>>> There are a lot of 0s and +1s for option [3] and two -1s
>>>>
>>>> Let me make a case for it to try and get consensus around it.
>>>>
>>>> I want to 'replace' the existing web console with something better.
>>>> For configuration activemq did not build a dependency injection
>>>> framework, we shipped spring.
>>>> Learning from that, it does not make sense to me that we build and
>>>> maintain a html5 web console.
>>>>
>>>> An admin/management web front end based over our extensive JMX api
>>>> sounds perfect but it needs
>>>> a community to evolve and improve it. We (activemq committers) have
>>>> proven that we need help in that area.
>>>>
>>>> Anyone what to change their vote or further expand on the technical
>>>> reasons we should not be branding hatwio?
>>>>
>>>>
>>>> On 17 January 2014 13:33, Robert Davies <ra...@gmail.com> wrote:
>>>>> I want to take a straw poll to see where everyone stands, because opinion has varied, mine included. Straw polls can be a useful tool to move towards consensus. This isn’t a formal vote, but to reduce the noise, can we keep it to binding votes only ?
>>>>>
>>>>>
>>>>> 1. Have one distribution with no default console, but make it easy to deploy a console on demand (the original console - or 3rd party ones).
>>>>> 2. Have two separate distributions, one with no console - and have a second distribution with the original console
>>>>> 3. One distribution, with hawtio as the console - ActiveMQ branded.
>>>>> 4. One distribution, but uses the original ActiveMQ console only.
>>>>>
>>>>> Here’s my vote:
>>>>>
>>>>> [1]. +1
>>>>> [2] 0
>>>>> [3] 0
>>>>> [4] -1
>>>>>
>>>>> thanks,
>>>>>
>>>>> Rob
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> http://redhat.com
>>>> http://blog.garytully.com
>>>
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>>
>>
>>
>>
>> --
>> http://redhat.com
>> http://blog.garytully.com
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
--
http://redhat.com
http://blog.garytully.com
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Daniel Kulp <dk...@apache.org>.
On Jan 21, 2014, at 12:07 PM, Gary Tully <ga...@gmail.com> wrote:
> On 21 January 2014 16:30, Daniel Kulp <dk...@apache.org> wrote:
>>
>> 2) All the ActiveMQ related code needs to be moved into the ActiveMQ project. If someone is using ActiveMQ and wants to contribute changes to how the console looks or displays items or such, they should be making contributions to ActiveMQ, not some external community (open source, free, or otherwise). The hawt.io “framework” of libraries and such can remain outside, but the ActiveMQ specific portions needs to be part of this community. If it’s going to be the visible frontend of this project, we need to make sure it drives the developer willing to contribute enhancements into ActiveMQ.
>>
> This is putting the cart before the horse!
> If we need some changes and if we can't make contributions to hawtio
> (patches, issues etc) we can deal with that by building our own plugin
> or throwing it out or whatever. But why do that now?
You are basically asking THIS developer community to completely give up control over how ActiveMQ is presented to the users to a different community. I personally cannot think of anything much worse for this community than that. That seems like a horrible idea from an Apache community standpoint.
The goals of the Apache communities needs to be to make sure developers are driven into the Apache communities, not another community.
> We don't have to own everything that makes activemq better and that
> makes our users experience better, we just have to ensure that it is
> better.
Making the user experience better is certainly an important aspect of the Apache communities, but the primary focus should be on making sure the developer community is healthy and we aren’t driving potential developers elsewhere. That NEEDS to be the most important thing at this point, especially with the current active makeup of this community.
In particular, since Apache is a 503b charitable non-profit foundation, we cannot be used to promote other communities, particularly those “owned” by a for-profit entity. (open source or otherwise, that’s somewhat irrelevant)
Anyway, as far as *I’m* concerned (but I’m not a member of this PMC, just an interested party), if the hawt.io community is unwilling or unable to support the ActiveMQ community to allow ActiveMQ to maintain control over it’s user experience, then there is no-point engaging with them. It is a waste of time.
That said, if hawt.io community want to create a full distribution of ActiveMQ + hawt.io to make life easier for users, they certainly are welcome to do so as long as it’s not branded ActiveMQ. (and again, not something to be promoted here)
Dan
> If the hawt.io community is unwilling (or unable) to do the second part, then, IMO, #3 is a non-starter. If they ARE willing to do that, then great. Lets start figuring out how to get that done. But that’s something that would need to be discussed on their side first.
>>
>>
>> Dan
>>
>>
>>
>> On Jan 21, 2014, at 10:55 AM, Gary Tully <ga...@gmail.com> wrote:
>>
>>> There are a lot of 0s and +1s for option [3] and two -1s
>>>
>>> Let me make a case for it to try and get consensus around it.
>>>
>>> I want to 'replace' the existing web console with something better.
>>> For configuration activemq did not build a dependency injection
>>> framework, we shipped spring.
>>> Learning from that, it does not make sense to me that we build and
>>> maintain a html5 web console.
>>>
>>> An admin/management web front end based over our extensive JMX api
>>> sounds perfect but it needs
>>> a community to evolve and improve it. We (activemq committers) have
>>> proven that we need help in that area.
>>>
>>> Anyone what to change their vote or further expand on the technical
>>> reasons we should not be branding hatwio?
>>>
>>>
>>> On 17 January 2014 13:33, Robert Davies <ra...@gmail.com> wrote:
>>>> I want to take a straw poll to see where everyone stands, because opinion has varied, mine included. Straw polls can be a useful tool to move towards consensus. This isn’t a formal vote, but to reduce the noise, can we keep it to binding votes only ?
>>>>
>>>>
>>>> 1. Have one distribution with no default console, but make it easy to deploy a console on demand (the original console - or 3rd party ones).
>>>> 2. Have two separate distributions, one with no console - and have a second distribution with the original console
>>>> 3. One distribution, with hawtio as the console - ActiveMQ branded.
>>>> 4. One distribution, but uses the original ActiveMQ console only.
>>>>
>>>> Here’s my vote:
>>>>
>>>> [1]. +1
>>>> [2] 0
>>>> [3] 0
>>>> [4] -1
>>>>
>>>> thanks,
>>>>
>>>> Rob
>>>>
>>>
>>>
>>>
>>> --
>>> http://redhat.com
>>> http://blog.garytully.com
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>
>
>
> --
> http://redhat.com
> http://blog.garytully.com
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Gary Tully <ga...@gmail.com>.
inline
On 21 January 2014 16:30, Daniel Kulp <dk...@apache.org> wrote:
>
> There is a huge difference between “needing help” in that area (as you put it) and “having someone else do it for us”.
>
This is my point. A new project has already done it and it is great
(being a great web ui is their whole reason for being).
We no longer need help we just need to embrace it.
> For #3 to work, IMO two things need to be done:
>
> 1) Skinning (obvious)
yes.
>
> 2) All the ActiveMQ related code needs to be moved into the ActiveMQ project. If someone is using ActiveMQ and wants to contribute changes to how the console looks or displays items or such, they should be making contributions to ActiveMQ, not some external community (open source, free, or otherwise). The hawt.io “framework” of libraries and such can remain outside, but the ActiveMQ specific portions needs to be part of this community. If it’s going to be the visible frontend of this project, we need to make sure it drives the developer willing to contribute enhancements into ActiveMQ.
>
This is putting the cart before the horse!
If we need some changes and if we can't make contributions to hawtio
(patches, issues etc) we can deal with that by building our own plugin
or throwing it out or whatever. But why do that now?
We don't have to own everything that makes activemq better and that
makes our users experience better, we just have to ensure that it is
better.
> If the hawt.io community is unwilling (or unable) to do the second part, then, IMO, #3 is a non-starter. If they ARE willing to do that, then great. Lets start figuring out how to get that done. But that’s something that would need to be discussed on their side first.
>
>
> Dan
>
>
>
> On Jan 21, 2014, at 10:55 AM, Gary Tully <ga...@gmail.com> wrote:
>
>> There are a lot of 0s and +1s for option [3] and two -1s
>>
>> Let me make a case for it to try and get consensus around it.
>>
>> I want to 'replace' the existing web console with something better.
>> For configuration activemq did not build a dependency injection
>> framework, we shipped spring.
>> Learning from that, it does not make sense to me that we build and
>> maintain a html5 web console.
>>
>> An admin/management web front end based over our extensive JMX api
>> sounds perfect but it needs
>> a community to evolve and improve it. We (activemq committers) have
>> proven that we need help in that area.
>>
>> Anyone what to change their vote or further expand on the technical
>> reasons we should not be branding hatwio?
>>
>>
>> On 17 January 2014 13:33, Robert Davies <ra...@gmail.com> wrote:
>>> I want to take a straw poll to see where everyone stands, because opinion has varied, mine included. Straw polls can be a useful tool to move towards consensus. This isn’t a formal vote, but to reduce the noise, can we keep it to binding votes only ?
>>>
>>>
>>> 1. Have one distribution with no default console, but make it easy to deploy a console on demand (the original console - or 3rd party ones).
>>> 2. Have two separate distributions, one with no console - and have a second distribution with the original console
>>> 3. One distribution, with hawtio as the console - ActiveMQ branded.
>>> 4. One distribution, but uses the original ActiveMQ console only.
>>>
>>> Here’s my vote:
>>>
>>> [1]. +1
>>> [2] 0
>>> [3] 0
>>> [4] -1
>>>
>>> thanks,
>>>
>>> Rob
>>>
>>
>>
>>
>> --
>> http://redhat.com
>> http://blog.garytully.com
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
--
http://redhat.com
http://blog.garytully.com
Re: [POLL] - Remove the old ActiveMQ Console
Posted by James Carman <ja...@carmanconsulting.com>.
On Tue, Jan 21, 2014 at 12:11 PM, Gary Tully <ga...@gmail.com> wrote:
> hadrian, it is the activemq devs that want to include hawtio, not the
> other way around.
> lets concentrate on what we (activemq devs/pmc) can do to make the web
> experience better.
> The only technical issue with hawtio in 5.9 is the branding. I say we
> just fix that.
>
You say that as if they are not one and the same.
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Stan Lewis <ga...@gmail.com>.
Just to address the technical question of skinning the console, we've a
vendor.js file just for that purpose. So at the simplest level skinning
would be a matter of extending the existing hawtio-web.war and replacing
the vendor.js file, and likely adding your own .css file.
So in vendor.js you could do (for example):
var link = $("<link>")
$("head").append(link);
link.attr({
rel: 'stylesheet',
type: 'text/css',
href: 'css/my-custom-css.css'
});
// ensure the built-in branding module doesn't kick in at all
Branding.enabled = false;
// then you need a plugin to customize the branding strings
angular.module('myBranding', ['hawtioCore',
'hawtio-branding']).run(function (branding) {
branding.appName = 'ActiveMQ Web Console';
branding.appLogo = 'img/branding/MyLogo.png';
branding.loginBg = 'img/branding/MyLoginScreen.png';
//gets rid of the header nav bar on the login screen
branding.fullscreenLogin = true;
);
hawtioPluginLoader.addModule('myBranding');
Then in my-custom-css.css you can rework the UI as much as you like really.
On Tue, Jan 21, 2014 at 1:46 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> And how exactly do you plan to achieve this without changes in hawt.io,
> and consequently buy-in from the hawt.io devs? Fork hawt.io?
>
> Hadrian
>
>
>
>
> On 01/21/2014 12:11 PM, Gary Tully wrote:
>
>> hadrian, it is the activemq devs that want to include hawtio, not the
>> other way around.
>> lets concentrate on what we (activemq devs/pmc) can do to make the web
>> experience better.
>> The only technical issue with hawtio in 5.9 is the branding. I say we
>> just fix that.
>>
>> On 21 January 2014 17:00, Hadrian Zbarcea <hz...@gmail.com> wrote:
>>
>>> Agree.
>>>
>>> In the other thread it was clarified why the hawt.io console in the
>>> current
>>> form cannot be included in the activemq distro. I would have expected the
>>> hawt.io devs to come with a proposal on how they plan to address that if
>>> they want #3 to happen. Suggestions were offered, but I saw no reply or
>>> feedback. Continuing this conversation without an understanding of what
>>> the
>>> hawt.io devs intentions are is, imo, not a great use of time.
>>>
>>> My $0.02,
>>> Hadrian
>>>
>>>
>>>
>>>
>>> On 01/21/2014 11:30 AM, Daniel Kulp wrote:
>>>
>>>>
>>>>
>>>> There is a huge difference between “needing help” in that area (as you
>>>> put
>>>> it) and “having someone else do it for us”.
>>>>
>>>> For #3 to work, IMO two things need to be done:
>>>>
>>>> 1) Skinning (obvious)
>>>>
>>>> 2) All the ActiveMQ related code needs to be moved into the ActiveMQ
>>>> project. If someone is using ActiveMQ and wants to contribute changes
>>>> to
>>>> how the console looks or displays items or such, they should be making
>>>> contributions to ActiveMQ, not some external community (open source,
>>>> free,
>>>> or otherwise). The hawt.io “framework” of libraries and such can
>>>> remain
>>>> outside, but the ActiveMQ specific portions needs to be part of this
>>>> community. If it’s going to be the visible frontend of this project,
>>>> we
>>>> need to make sure it drives the developer willing to contribute
>>>> enhancements
>>>> into ActiveMQ.
>>>>
>>>> If the hawt.io community is unwilling (or unable) to do the second
>>>> part,
>>>> then, IMO, #3 is a non-starter. If they ARE willing to do that, then
>>>> great.
>>>> Lets start figuring out how to get that done. But that’s something
>>>> that
>>>> would need to be discussed on their side first.
>>>>
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>> On Jan 21, 2014, at 10:55 AM, Gary Tully <ga...@gmail.com> wrote:
>>>>
>>>> There are a lot of 0s and +1s for option [3] and two -1s
>>>>>
>>>>> Let me make a case for it to try and get consensus around it.
>>>>>
>>>>> I want to 'replace' the existing web console with something better.
>>>>> For configuration activemq did not build a dependency injection
>>>>> framework, we shipped spring.
>>>>> Learning from that, it does not make sense to me that we build and
>>>>> maintain a html5 web console.
>>>>>
>>>>> An admin/management web front end based over our extensive JMX api
>>>>> sounds perfect but it needs
>>>>> a community to evolve and improve it. We (activemq committers) have
>>>>> proven that we need help in that area.
>>>>>
>>>>> Anyone what to change their vote or further expand on the technical
>>>>> reasons we should not be branding hatwio?
>>>>>
>>>>>
>>>>> On 17 January 2014 13:33, Robert Davies <ra...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>> I want to take a straw poll to see where everyone stands, because
>>>>>> opinion has varied, mine included. Straw polls can be a useful tool
>>>>>> to move
>>>>>> towards consensus. This isn’t a formal vote, but to reduce the noise,
>>>>>> can we
>>>>>> keep it to binding votes only ?
>>>>>>
>>>>>>
>>>>>> 1. Have one distribution with no default console, but make it easy to
>>>>>> deploy a console on demand (the original console - or 3rd party ones).
>>>>>> 2. Have two separate distributions, one with no console - and have a
>>>>>> second distribution with the original console
>>>>>> 3. One distribution, with hawtio as the console - ActiveMQ branded.
>>>>>> 4. One distribution, but uses the original ActiveMQ console only.
>>>>>>
>>>>>> Here’s my vote:
>>>>>>
>>>>>> [1]. +1
>>>>>> [2] 0
>>>>>> [3] 0
>>>>>> [4] -1
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> Rob
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://redhat.com
>>>>> http://blog.garytully.com
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Hadrian Zbarcea <hz...@gmail.com>.
And how exactly do you plan to achieve this without changes in hawt.io,
and consequently buy-in from the hawt.io devs? Fork hawt.io?
Hadrian
On 01/21/2014 12:11 PM, Gary Tully wrote:
> hadrian, it is the activemq devs that want to include hawtio, not the
> other way around.
> lets concentrate on what we (activemq devs/pmc) can do to make the web
> experience better.
> The only technical issue with hawtio in 5.9 is the branding. I say we
> just fix that.
>
> On 21 January 2014 17:00, Hadrian Zbarcea <hz...@gmail.com> wrote:
>> Agree.
>>
>> In the other thread it was clarified why the hawt.io console in the current
>> form cannot be included in the activemq distro. I would have expected the
>> hawt.io devs to come with a proposal on how they plan to address that if
>> they want #3 to happen. Suggestions were offered, but I saw no reply or
>> feedback. Continuing this conversation without an understanding of what the
>> hawt.io devs intentions are is, imo, not a great use of time.
>>
>> My $0.02,
>> Hadrian
>>
>>
>>
>>
>> On 01/21/2014 11:30 AM, Daniel Kulp wrote:
>>>
>>>
>>> There is a huge difference between “needing help” in that area (as you put
>>> it) and “having someone else do it for us”.
>>>
>>> For #3 to work, IMO two things need to be done:
>>>
>>> 1) Skinning (obvious)
>>>
>>> 2) All the ActiveMQ related code needs to be moved into the ActiveMQ
>>> project. If someone is using ActiveMQ and wants to contribute changes to
>>> how the console looks or displays items or such, they should be making
>>> contributions to ActiveMQ, not some external community (open source, free,
>>> or otherwise). The hawt.io “framework” of libraries and such can remain
>>> outside, but the ActiveMQ specific portions needs to be part of this
>>> community. If it’s going to be the visible frontend of this project, we
>>> need to make sure it drives the developer willing to contribute enhancements
>>> into ActiveMQ.
>>>
>>> If the hawt.io community is unwilling (or unable) to do the second part,
>>> then, IMO, #3 is a non-starter. If they ARE willing to do that, then great.
>>> Lets start figuring out how to get that done. But that’s something that
>>> would need to be discussed on their side first.
>>>
>>>
>>> Dan
>>>
>>>
>>>
>>> On Jan 21, 2014, at 10:55 AM, Gary Tully <ga...@gmail.com> wrote:
>>>
>>>> There are a lot of 0s and +1s for option [3] and two -1s
>>>>
>>>> Let me make a case for it to try and get consensus around it.
>>>>
>>>> I want to 'replace' the existing web console with something better.
>>>> For configuration activemq did not build a dependency injection
>>>> framework, we shipped spring.
>>>> Learning from that, it does not make sense to me that we build and
>>>> maintain a html5 web console.
>>>>
>>>> An admin/management web front end based over our extensive JMX api
>>>> sounds perfect but it needs
>>>> a community to evolve and improve it. We (activemq committers) have
>>>> proven that we need help in that area.
>>>>
>>>> Anyone what to change their vote or further expand on the technical
>>>> reasons we should not be branding hatwio?
>>>>
>>>>
>>>> On 17 January 2014 13:33, Robert Davies <ra...@gmail.com> wrote:
>>>>>
>>>>> I want to take a straw poll to see where everyone stands, because
>>>>> opinion has varied, mine included. Straw polls can be a useful tool to move
>>>>> towards consensus. This isn’t a formal vote, but to reduce the noise, can we
>>>>> keep it to binding votes only ?
>>>>>
>>>>>
>>>>> 1. Have one distribution with no default console, but make it easy to
>>>>> deploy a console on demand (the original console - or 3rd party ones).
>>>>> 2. Have two separate distributions, one with no console - and have a
>>>>> second distribution with the original console
>>>>> 3. One distribution, with hawtio as the console - ActiveMQ branded.
>>>>> 4. One distribution, but uses the original ActiveMQ console only.
>>>>>
>>>>> Here’s my vote:
>>>>>
>>>>> [1]. +1
>>>>> [2] 0
>>>>> [3] 0
>>>>> [4] -1
>>>>>
>>>>> thanks,
>>>>>
>>>>> Rob
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> http://redhat.com
>>>> http://blog.garytully.com
>>>
>>>
>>
>
>
>
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Gary Tully <ga...@gmail.com>.
hadrian, it is the activemq devs that want to include hawtio, not the
other way around.
lets concentrate on what we (activemq devs/pmc) can do to make the web
experience better.
The only technical issue with hawtio in 5.9 is the branding. I say we
just fix that.
On 21 January 2014 17:00, Hadrian Zbarcea <hz...@gmail.com> wrote:
> Agree.
>
> In the other thread it was clarified why the hawt.io console in the current
> form cannot be included in the activemq distro. I would have expected the
> hawt.io devs to come with a proposal on how they plan to address that if
> they want #3 to happen. Suggestions were offered, but I saw no reply or
> feedback. Continuing this conversation without an understanding of what the
> hawt.io devs intentions are is, imo, not a great use of time.
>
> My $0.02,
> Hadrian
>
>
>
>
> On 01/21/2014 11:30 AM, Daniel Kulp wrote:
>>
>>
>> There is a huge difference between “needing help” in that area (as you put
>> it) and “having someone else do it for us”.
>>
>> For #3 to work, IMO two things need to be done:
>>
>> 1) Skinning (obvious)
>>
>> 2) All the ActiveMQ related code needs to be moved into the ActiveMQ
>> project. If someone is using ActiveMQ and wants to contribute changes to
>> how the console looks or displays items or such, they should be making
>> contributions to ActiveMQ, not some external community (open source, free,
>> or otherwise). The hawt.io “framework” of libraries and such can remain
>> outside, but the ActiveMQ specific portions needs to be part of this
>> community. If it’s going to be the visible frontend of this project, we
>> need to make sure it drives the developer willing to contribute enhancements
>> into ActiveMQ.
>>
>> If the hawt.io community is unwilling (or unable) to do the second part,
>> then, IMO, #3 is a non-starter. If they ARE willing to do that, then great.
>> Lets start figuring out how to get that done. But that’s something that
>> would need to be discussed on their side first.
>>
>>
>> Dan
>>
>>
>>
>> On Jan 21, 2014, at 10:55 AM, Gary Tully <ga...@gmail.com> wrote:
>>
>>> There are a lot of 0s and +1s for option [3] and two -1s
>>>
>>> Let me make a case for it to try and get consensus around it.
>>>
>>> I want to 'replace' the existing web console with something better.
>>> For configuration activemq did not build a dependency injection
>>> framework, we shipped spring.
>>> Learning from that, it does not make sense to me that we build and
>>> maintain a html5 web console.
>>>
>>> An admin/management web front end based over our extensive JMX api
>>> sounds perfect but it needs
>>> a community to evolve and improve it. We (activemq committers) have
>>> proven that we need help in that area.
>>>
>>> Anyone what to change their vote or further expand on the technical
>>> reasons we should not be branding hatwio?
>>>
>>>
>>> On 17 January 2014 13:33, Robert Davies <ra...@gmail.com> wrote:
>>>>
>>>> I want to take a straw poll to see where everyone stands, because
>>>> opinion has varied, mine included. Straw polls can be a useful tool to move
>>>> towards consensus. This isn’t a formal vote, but to reduce the noise, can we
>>>> keep it to binding votes only ?
>>>>
>>>>
>>>> 1. Have one distribution with no default console, but make it easy to
>>>> deploy a console on demand (the original console - or 3rd party ones).
>>>> 2. Have two separate distributions, one with no console - and have a
>>>> second distribution with the original console
>>>> 3. One distribution, with hawtio as the console - ActiveMQ branded.
>>>> 4. One distribution, but uses the original ActiveMQ console only.
>>>>
>>>> Here’s my vote:
>>>>
>>>> [1]. +1
>>>> [2] 0
>>>> [3] 0
>>>> [4] -1
>>>>
>>>> thanks,
>>>>
>>>> Rob
>>>>
>>>
>>>
>>>
>>> --
>>> http://redhat.com
>>> http://blog.garytully.com
>>
>>
>
--
http://redhat.com
http://blog.garytully.com
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Agree.
In the other thread it was clarified why the hawt.io console in the
current form cannot be included in the activemq distro. I would have
expected the hawt.io devs to come with a proposal on how they plan to
address that if they want #3 to happen. Suggestions were offered, but I
saw no reply or feedback. Continuing this conversation without an
understanding of what the hawt.io devs intentions are is, imo, not a
great use of time.
My $0.02,
Hadrian
On 01/21/2014 11:30 AM, Daniel Kulp wrote:
>
> There is a huge difference between “needing help” in that area (as you put it) and “having someone else do it for us”.
>
> For #3 to work, IMO two things need to be done:
>
> 1) Skinning (obvious)
>
> 2) All the ActiveMQ related code needs to be moved into the ActiveMQ project. If someone is using ActiveMQ and wants to contribute changes to how the console looks or displays items or such, they should be making contributions to ActiveMQ, not some external community (open source, free, or otherwise). The hawt.io “framework” of libraries and such can remain outside, but the ActiveMQ specific portions needs to be part of this community. If it’s going to be the visible frontend of this project, we need to make sure it drives the developer willing to contribute enhancements into ActiveMQ.
>
> If the hawt.io community is unwilling (or unable) to do the second part, then, IMO, #3 is a non-starter. If they ARE willing to do that, then great. Lets start figuring out how to get that done. But that’s something that would need to be discussed on their side first.
>
>
> Dan
>
>
>
> On Jan 21, 2014, at 10:55 AM, Gary Tully <ga...@gmail.com> wrote:
>
>> There are a lot of 0s and +1s for option [3] and two -1s
>>
>> Let me make a case for it to try and get consensus around it.
>>
>> I want to 'replace' the existing web console with something better.
>> For configuration activemq did not build a dependency injection
>> framework, we shipped spring.
>> Learning from that, it does not make sense to me that we build and
>> maintain a html5 web console.
>>
>> An admin/management web front end based over our extensive JMX api
>> sounds perfect but it needs
>> a community to evolve and improve it. We (activemq committers) have
>> proven that we need help in that area.
>>
>> Anyone what to change their vote or further expand on the technical
>> reasons we should not be branding hatwio?
>>
>>
>> On 17 January 2014 13:33, Robert Davies <ra...@gmail.com> wrote:
>>> I want to take a straw poll to see where everyone stands, because opinion has varied, mine included. Straw polls can be a useful tool to move towards consensus. This isn’t a formal vote, but to reduce the noise, can we keep it to binding votes only ?
>>>
>>>
>>> 1. Have one distribution with no default console, but make it easy to deploy a console on demand (the original console - or 3rd party ones).
>>> 2. Have two separate distributions, one with no console - and have a second distribution with the original console
>>> 3. One distribution, with hawtio as the console - ActiveMQ branded.
>>> 4. One distribution, but uses the original ActiveMQ console only.
>>>
>>> Here’s my vote:
>>>
>>> [1]. +1
>>> [2] 0
>>> [3] 0
>>> [4] -1
>>>
>>> thanks,
>>>
>>> Rob
>>>
>>
>>
>>
>> --
>> http://redhat.com
>> http://blog.garytully.com
>
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Daniel Kulp <dk...@apache.org>.
There is a huge difference between “needing help” in that area (as you put it) and “having someone else do it for us”.
For #3 to work, IMO two things need to be done:
1) Skinning (obvious)
2) All the ActiveMQ related code needs to be moved into the ActiveMQ project. If someone is using ActiveMQ and wants to contribute changes to how the console looks or displays items or such, they should be making contributions to ActiveMQ, not some external community (open source, free, or otherwise). The hawt.io “framework” of libraries and such can remain outside, but the ActiveMQ specific portions needs to be part of this community. If it’s going to be the visible frontend of this project, we need to make sure it drives the developer willing to contribute enhancements into ActiveMQ.
If the hawt.io community is unwilling (or unable) to do the second part, then, IMO, #3 is a non-starter. If they ARE willing to do that, then great. Lets start figuring out how to get that done. But that’s something that would need to be discussed on their side first.
Dan
On Jan 21, 2014, at 10:55 AM, Gary Tully <ga...@gmail.com> wrote:
> There are a lot of 0s and +1s for option [3] and two -1s
>
> Let me make a case for it to try and get consensus around it.
>
> I want to 'replace' the existing web console with something better.
> For configuration activemq did not build a dependency injection
> framework, we shipped spring.
> Learning from that, it does not make sense to me that we build and
> maintain a html5 web console.
>
> An admin/management web front end based over our extensive JMX api
> sounds perfect but it needs
> a community to evolve and improve it. We (activemq committers) have
> proven that we need help in that area.
>
> Anyone what to change their vote or further expand on the technical
> reasons we should not be branding hatwio?
>
>
> On 17 January 2014 13:33, Robert Davies <ra...@gmail.com> wrote:
>> I want to take a straw poll to see where everyone stands, because opinion has varied, mine included. Straw polls can be a useful tool to move towards consensus. This isn’t a formal vote, but to reduce the noise, can we keep it to binding votes only ?
>>
>>
>> 1. Have one distribution with no default console, but make it easy to deploy a console on demand (the original console - or 3rd party ones).
>> 2. Have two separate distributions, one with no console - and have a second distribution with the original console
>> 3. One distribution, with hawtio as the console - ActiveMQ branded.
>> 4. One distribution, but uses the original ActiveMQ console only.
>>
>> Here’s my vote:
>>
>> [1]. +1
>> [2] 0
>> [3] 0
>> [4] -1
>>
>> thanks,
>>
>> Rob
>>
>
>
>
> --
> http://redhat.com
> http://blog.garytully.com
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Gary Tully <ga...@gmail.com>.
There are a lot of 0s and +1s for option [3] and two -1s
Let me make a case for it to try and get consensus around it.
I want to 'replace' the existing web console with something better.
For configuration activemq did not build a dependency injection
framework, we shipped spring.
Learning from that, it does not make sense to me that we build and
maintain a html5 web console.
An admin/management web front end based over our extensive JMX api
sounds perfect but it needs
a community to evolve and improve it. We (activemq committers) have
proven that we need help in that area.
Anyone what to change their vote or further expand on the technical
reasons we should not be branding hatwio?
On 17 January 2014 13:33, Robert Davies <ra...@gmail.com> wrote:
> I want to take a straw poll to see where everyone stands, because opinion has varied, mine included. Straw polls can be a useful tool to move towards consensus. This isn’t a formal vote, but to reduce the noise, can we keep it to binding votes only ?
>
>
> 1. Have one distribution with no default console, but make it easy to deploy a console on demand (the original console - or 3rd party ones).
> 2. Have two separate distributions, one with no console - and have a second distribution with the original console
> 3. One distribution, with hawtio as the console - ActiveMQ branded.
> 4. One distribution, but uses the original ActiveMQ console only.
>
> Here’s my vote:
>
> [1]. +1
> [2] 0
> [3] 0
> [4] -1
>
> thanks,
>
> Rob
>
--
http://redhat.com
http://blog.garytully.com
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Dejan Bosanac <de...@nighttale.net>.
[1] +1
[2] -1
[3] +1
[4] -1
Regards
--
Dejan Bosanac
----------------------
Red Hat, Inc.
FuseSource is now part of Red Hat
dbosanac@redhat.com
Twitter: @dejanb
Blog: http://sensatic.net
ActiveMQ in Action: http://www.manning.com/snyder/
On Fri, Jan 17, 2014 at 2:33 PM, Robert Davies <ra...@gmail.com> wrote:
> I want to take a straw poll to see where everyone stands, because opinion
> has varied, mine included. Straw polls can be a useful tool to move towards
> consensus. This isn’t a formal vote, but to reduce the noise, can we keep
> it to binding votes only ?
>
>
> 1. Have one distribution with no default console, but make it easy to
> deploy a console on demand (the original console - or 3rd party ones).
> 2. Have two separate distributions, one with no console - and have a
> second distribution with the original console
> 3. One distribution, with hawtio as the console - ActiveMQ branded.
> 4. One distribution, but uses the original ActiveMQ console only.
>
> Here’s my vote:
>
> [1]. +1
> [2] 0
> [3] 0
> [4] -1
>
> thanks,
>
> Rob
>
>
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Robert Davies <ra...@gmail.com>.
>
> Another -1 for the idea of not including users/devs/committers in this poll. Their voice counts.
Yes - not ideal but if we can’t get consensus amongst a smaller group, there’s no hope of a larger one. So just starting small to see what happens.
>
>
>
> On 01/17/2014 08:33 AM, Robert Davies wrote:
>> I want to take a straw poll to see where everyone stands, because opinion has varied, mine included. Straw polls can be a useful tool to move towards consensus. This isn’t a formal vote, but to reduce the noise, can we keep it to binding votes only ?
>>
>>
>> 1. Have one distribution with no default console, but make it easy to deploy a console on demand (the original console - or 3rd party ones).
>> 2. Have two separate distributions, one with no console - and have a second distribution with the original console
>> 3. One distribution, with hawtio as the console - ActiveMQ branded.
>> 4. One distribution, but uses the original ActiveMQ console only.
>>
>> Here’s my vote:
>>
>> [1]. +1
>> [2] 0
>> [3] 0
>> [4] -1
>>
>> thanks,
>>
>> Rob
>>
Rob Davies
————————
Red Hat, Inc
http://hawt.io - #dontcha
Twitter: rajdavies
Blog: http://rajdavies.blogspot.com
ActiveMQ in Action: http://www.manning.com/snyder/
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Hadrian Zbarcea <hz...@gmail.com>.
[1] -1 (not a great idea to remove something still used and useful)
[2] +1 (status quo)
[3] -1 (unless relevant parts were donated to the ASF)
[4] +1 (status quo)
Another -1 for the idea of not including users/devs/committers in this
poll. Their voice counts.
Hadrian
On 01/17/2014 08:33 AM, Robert Davies wrote:
> I want to take a straw poll to see where everyone stands, because opinion has varied, mine included. Straw polls can be a useful tool to move towards consensus. This isn’t a formal vote, but to reduce the noise, can we keep it to binding votes only ?
>
>
> 1. Have one distribution with no default console, but make it easy to deploy a console on demand (the original console - or 3rd party ones).
> 2. Have two separate distributions, one with no console - and have a second distribution with the original console
> 3. One distribution, with hawtio as the console - ActiveMQ branded.
> 4. One distribution, but uses the original ActiveMQ console only.
>
> Here’s my vote:
>
> [1]. +1
> [2] 0
> [3] 0
> [4] -1
>
> thanks,
>
> Rob
>
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Jan 17, 2014 at 2:33 PM, Robert Davies <ra...@gmail.com> wrote:
> I want to take a straw poll to see where everyone stands, because opinion has varied, mine included. Straw polls can be a useful tool to move towards consensus. This isn’t a formal vote, but to reduce the noise, can we keep it to binding votes only ?
>
>
> 1. Have one distribution with no default console, but make it easy to deploy a console on demand (the original console - or 3rd party ones).
> 2. Have two separate distributions, one with no console - and have a second distribution with the original console
> 3. One distribution, with hawtio as the console - ActiveMQ branded.
> 4. One distribution, but uses the original ActiveMQ console only.
>
> Here’s my vote:
>
> [1]. +1
> [2] 0
> [3] 0
> [4] -1
>
> thanks,
>
> Rob
>
[1]: +1
[2]: -1 - there should be an even playing field for consoles. And the
original console should be moved to a sub project, where it has its
own release schedule. Installing any console into AMQ should be
similar and the same for all consoles, such as copying a .war into a
special directory. And optionally copy a configuration file into the
same dir, to override the default configuration of that installed
console. So ActiveMQ should have only one distribution, to have even
playing field. But installing a console is end user choice, and they
can choose what console to install / use if they want.
[3]: -1: see #2
[4]: -1
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Make your Camel applications look hawt, try: http://hawt.io
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Timothy Bish <ta...@gmail.com>.
[1] +1
[2] -1
[3] 0
[4] -1
On 01/17/2014 08:33 AM, Robert Davies wrote:
> I want to take a straw poll to see where everyone stands, because opinion has varied, mine included. Straw polls can be a useful tool to move towards consensus. This isn’t a formal vote, but to reduce the noise, can we keep it to binding votes only ?
>
>
> 1. Have one distribution with no default console, but make it easy to deploy a console on demand (the original console - or 3rd party ones).
> 2. Have two separate distributions, one with no console - and have a second distribution with the original console
> 3. One distribution, with hawtio as the console - ActiveMQ branded.
> 4. One distribution, but uses the original ActiveMQ console only.
>
> Here’s my vote:
>
> [1]. +1
> [2] 0
> [3] 0
> [4] -1
>
> thanks,
>
> Rob
>
>
--
Tim Bish
Sr Software Engineer | RedHat Inc.
tim.bish@redhat.com | www.fusesource.com | www.redhat.com
skype: tabish121 | twitter: @tabish121
blog: http://timbish.blogspot.com/
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Christian Posta <ch...@gmail.com>.
[1] +1 -- this gives the user choice -- if they choose the old
console, they accept the risks by doing so
[2] -1 -- this still endorses the old console, which should be treated
as deprecated, EOL, and removed
[3] 0 -- this seems to be a huge can of worms, yet probably beneficial
for the community
[4] -1 -- this still endorses the old console, which should be treated
as deprecated, EOL, and removed
On Fri, Jan 17, 2014 at 6:33 AM, Robert Davies <ra...@gmail.com> wrote:
> I want to take a straw poll to see where everyone stands, because opinion has varied, mine included. Straw polls can be a useful tool to move towards consensus. This isn’t a formal vote, but to reduce the noise, can we keep it to binding votes only ?
>
>
> 1. Have one distribution with no default console, but make it easy to deploy a console on demand (the original console - or 3rd party ones).
> 2. Have two separate distributions, one with no console - and have a second distribution with the original console
> 3. One distribution, with hawtio as the console - ActiveMQ branded.
> 4. One distribution, but uses the original ActiveMQ console only.
>
> Here’s my vote:
>
> [1]. +1
> [2] 0
> [3] 0
> [4] -1
>
> thanks,
>
> Rob
>
--
Christian Posta
http://www.christianposta.com/blog
twitter: @christianposta
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Hiram Chirino <hi...@hiramchirino.com>.
[1] +1 This would let users choose which console they want.
[2] -1 I think having 2 distros would just add confusion for end users.
[3] 0 As long as it's ActiveMQ branded, then it works for me.
[4] -1 The original console is a liability that I'd rather not carry anymore.
On Fri, Jan 17, 2014 at 8:33 AM, Robert Davies <ra...@gmail.com> wrote:
> I want to take a straw poll to see where everyone stands, because opinion has varied, mine included. Straw polls can be a useful tool to move towards consensus. This isn’t a formal vote, but to reduce the noise, can we keep it to binding votes only ?
>
>
> 1. Have one distribution with no default console, but make it easy to deploy a console on demand (the original console - or 3rd party ones).
> 2. Have two separate distributions, one with no console - and have a second distribution with the original console
> 3. One distribution, with hawtio as the console - ActiveMQ branded.
> 4. One distribution, but uses the original ActiveMQ console only.
>
> Here’s my vote:
>
> [1]. +1
> [2] 0
> [3] 0
> [4] -1
>
> thanks,
>
> Rob
>
--
Hiram Chirino
Engineering | Red Hat, Inc.
hchirino@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino
blog: Hiram Chirino's Bit Mojo
Re: [POLL] - Remove the old ActiveMQ Console
Posted by Jim Gomes <e....@gmail.com>.
[1] -1
[2] 0
[3] +1
[4] +1
Using the webconsole for development/debugging purposes is extremely
helpful. When moving to production systems, it should be a simple matter
to turn it off. This is no different than removing debug code from your
build when deploying.
On Fri, Jan 17, 2014 at 5:33 AM, Robert Davies <ra...@gmail.com> wrote:
> I want to take a straw poll to see where everyone stands, because opinion
> has varied, mine included. Straw polls can be a useful tool to move towards
> consensus. This isn’t a formal vote, but to reduce the noise, can we keep
> it to binding votes only ?
>
>
> 1. Have one distribution with no default console, but make it easy to
> deploy a console on demand (the original console - or 3rd party ones).
> 2. Have two separate distributions, one with no console - and have a
> second distribution with the original console
> 3. One distribution, with hawtio as the console - ActiveMQ branded.
> 4. One distribution, but uses the original ActiveMQ console only.
>
> Here’s my vote:
>
> [1]. +1
> [2] 0
> [3] 0
> [4] -1
>
> thanks,
>
> Rob
>
>
Re: [POLL] - Remove the old ActiveMQ Console
Posted by James Strachan <ja...@gmail.com>.
[1] +1
[2] -1 since we'd be effectively endorsing deprecated, dead code which is
potentially a security risk. I'd change this to a 0 if we clearly called
the distro "apache-activemq-deprecated-distro" or something to highlight
users are using dead, unmaintained code that probably has security
vulnerabilities
[3] 0
[4] -1
On 17 January 2014 13:33, Robert Davies <ra...@gmail.com> wrote:
> I want to take a straw poll to see where everyone stands, because opinion
> has varied, mine included. Straw polls can be a useful tool to move towards
> consensus. This isn’t a formal vote, but to reduce the noise, can we keep
> it to binding votes only ?
>
>
> 1. Have one distribution with no default console, but make it easy to
> deploy a console on demand (the original console - or 3rd party ones).
> 2. Have two separate distributions, one with no console - and have a
> second distribution with the original console
> 3. One distribution, with hawtio as the console - ActiveMQ branded.
> 4. One distribution, but uses the original ActiveMQ console only.
>
> Here’s my vote:
>
> [1]. +1
> [2] 0
> [3] 0
> [4] -1
>
> thanks,
>
> Rob
>
>
--
James
-------
Red Hat
Email: jstracha@redhat.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration