Re: [POLL] - Remove the old ActiveMQ Console
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 hzbar...@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
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 dbosa...@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 gary.tu...@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 gary.tu...@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
Re: [POLL] - Remove the old ActiveMQ Console
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 dbosa...@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 gary.tu...@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 gary.tu...@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
On Jan 21, 2014, at 5:16 PM, Gary Tully gary.tu...@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 gary.tu...@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 rajdav...@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,
Re: [POLL] - Remove the old ActiveMQ Console
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. hchir...@redhat.com | fusesource.com | redhat.com skype: hiramchirino | twitter: @hiramchirino
Re: [POLL] - Remove the old ActiveMQ Console
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. hchir...@redhat.com | fusesource.com | redhat.com skype: hiramchirino | twitter: @hiramchirino
Re: [POLL] - Remove the old ActiveMQ Console
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. hchir...@redhat.com | fusesource.com | redhat.com skype: hiramchirino | twitter: @hiramchirino
Re: [POLL] - Remove the old ActiveMQ Console
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. hchir...@redhat.com | fusesource.com | redhat.com skype: hiramchirino | twitter: @hiramchirino
Re: [POLL] - Remove the old ActiveMQ Console
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
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 rajdav...@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
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 gary.tu...@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 rajdav...@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 dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [POLL] - Remove the old ActiveMQ Console
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 gary.tu...@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 rajdav...@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
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 gary.tu...@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 rajdav...@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 dk...@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
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 hzbar...@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 gary.tu...@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 rajdav...@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
On Jan 21, 2014, at 12:07 PM, Gary Tully gary.tu...@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 gary.tu...@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 rajdav...@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 dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- http://redhat.com http://blog.garytully.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [POLL] - Remove the old ActiveMQ Console
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 gary.tu...@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 gary.tu...@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 rajdav...@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 -
Re: [POLL] - Remove the old ActiveMQ Console
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 hzbar...@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 gary.tu...@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 rajdav...@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
On Tue, Jan 21, 2014 at 12:11 PM, Gary Tully gary.tu...@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
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 hzbar...@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 hzbar...@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 gary.tu...@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 rajdav...@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
On Jan 21, 2014, at 1:15 PM, Jon Anstey jans...@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 gary.tu...@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
Re: [POLL] - Remove the old ActiveMQ Console
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 jans...@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 gary.tu...@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
Re: [POLL] - Remove the old ActiveMQ Console
inline On 21 January 2014 17:36, Daniel Kulp dk...@apache.org wrote: On Jan 21, 2014, at 12:07 PM, Gary Tully gary.tu...@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 gary.tu...@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 rajdav...@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
Re: [POLL] - Remove the old ActiveMQ Console
[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 rajdav...@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
[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
[1] +1 [2] -1 [3] +1 [4] -1 Regards -- Dejan Bosanac -- Red Hat, Inc. FuseSource is now part of Red Hat dbosa...@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 rajdav...@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
[1] 0 [2] -1 [3] +1 [4] -1 On 17 January 2014 13:33, Robert Davies rajdav...@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
On Fri, Jan 17, 2014 at 2:33 PM, Robert Davies rajdav...@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: cib...@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
[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 rajdav...@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
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 rajdav...@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
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 rajdav...@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
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 rajdav...@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
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 hzbar...@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 rajdav...@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
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
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 hzbar...@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 rajdav...@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
Karaf ships with a console On Friday, January 17, 2014, Robert Davies rajdav...@gmail.com wrote: On 17 Jan 2014, at 16:33, James Carman ja...@carmanconsulting.comjavascript:; 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 hzbar...@gmail.comjavascript:; 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 rajdav...@gmail.comjavascript:; 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
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 rajdav...@gmail.com wrote: On 17 Jan 2014, at 16:33, James Carman ja...@carmanconsulting.comjavascript:; 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 hzbar...@gmail.comjavascript:; 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 rajdav...@gmail.comjavascript:; 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
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 hzbar...@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 rajdav...@gmail.com wrote: On 17 Jan 2014, at 16:33, James Carman ja...@carmanconsulting.comjavascript:; 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 hzbar...@gmail.comjavascript:; 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 rajdav...@gmail.comjavascript:; 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
I said console in my statement, not web console. You need a way to manage stuff. On Friday, January 17, 2014, Christian Posta christian.po...@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 hzbar...@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 rajdav...@gmail.com wrote: On 17 Jan 2014, at 16:33, James Carman ja...@carmanconsulting.comjavascript:; 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 hzbar...@gmail.comjavascript:; 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 rajdav...@gmail.comjavascript:; -- Christian Posta http://www.christianposta.com/blog twitter: @christianposta
