Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of claus.ibsen@gmail.com
 designates 209.85.223.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <BD55BBF2-1F25-479B-B9B7-47865770F7FF@gmail.com>
References: <BD55BBF2-1F25-479B-B9B7-47865770F7FF@gmail.com>
From: Claus Ibsen <claus.ibsen@gmail.com>
Date: Mon, 27 Jan 2014 12:19:48 +0100
Message-ID: 
 <CAGB5yNnMs8rC4zo=v65uxB2HpWyMqcg4YLutfgkHV+v78saKsw@mail.gmail.com>
Subject: Re: [DISCUSS] Create an ActiveMQ Web Console sub-project
To: dev@activemq.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Sat, Jan 25, 2014 at 10:23 AM, Robert Davies <rajdavies@gmail.com> wrote=
:
>
> The recent poll [1] and discussions [2] around what to do with the curren=
t ActiveMQ web console demonstrated there=92s a mix bag of views. There are=
 developers who passionately believe that the current Web Console is a larg=
e technical debt on the project, hasn=92t been actively developed for years=
 and is a security risk - whilst others believe it benefits users immensely=
 to have such a web console available.
>
> What I would like to propose is that the Web Console is moved to a sub pr=
oject of ActiveMQ - where those interested in maintaining and developing it=
 can work independently of the ActiveMQ broker release. Ideally there would=
 be collaboration - so that the Web console could be released in the same t=
ime frame as every new minor and major release of the broker. However, havi=
ng it as a sub project will also allow for it to be released independently =
- so that if folks want to iterate releases of the web console whilst they =
improve it or to fix issues as they arise they can. It also has the benefit=
 of freeing up ActiveMQ developers who want to concentrate on the core brok=
er functionality.
>

Yeah a good idea to move into a sub project, which I also said on the
other threads on @dev recently.

ActiveMQ has other sub projects for other things like the adapters for
C/C# and the likes.
And other ASF projects has sub projects for their web consoles such as
Karaf/Felix.
And other ASF projects include web consoles from other ASF projects /
sub projects in their distribution such as SMX/Karaf.

And as you say it allows the web console to be released independently
from AMQ, which allows to release it with bug fixes, new features and
improvements and whatnot. As well supporting multiple versions of AMQ.
And more importantly it allows end users to keep the same broker
version but upgrade their web console. Which is a huge win, as
upgrading the broker is much much more complicated / time effort, than
just a optional web console for the UI.

The ActiveMQ project can then include the released web console in its
distribution. This is how other ASF projects also do it.


> This is a compromise, but I believe its the best way forward. What do you=
 guys think ?
>
> thanks,
>
> Rob
>
> [1] https://www.mail-archive.com/dev@activemq.apache.org/msg37711.html
> [2] http://activemq.2283324.n4.nabble.com/DISCUSS-Remove-the-old-ActiveMQ=
-Console-td4675925.html
>
> Rob Davies
> =97=97=97=97=97=97=97=97
> Red Hat, Inc
> http://hawt.io - #dontcha
> Twitter: rajdavies
> Blog: http://rajdavies.blogspot.com
> ActiveMQ in Action: http://www.manning.com/snyder/
>


--=20
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Make your Camel applications look hawt, try: http://hawt.io