+1 for removing it completely. As Hadrian said, we (the Camel project itself) should focus on the server side technology that we do so well.
Other projects like Karaf WebConsole, Hawt.io, Camelwatch, ... are better places to provide this kind of management functionality via a gui/console/... After some time we will see which of these projects succeed and we may decide to support the one or the others (what ever "supports" will mean - link from the Camel web site, writing a plug in, writing an example, ...). Best, Christian On Sat, Jan 26, 2013 at 6:42 PM, Jon Anstey <jans...@gmail.com> wrote: > +1 to remove the web console for Camel 3.0 (option #2) > On 2013-01-25 8:14 PM, "Hadrian Zbarcea" <hzbar...@gmail.com> wrote: > > > I'd keep this thread short and focus on achieving consensus (if possible) > > on what to do with the existing console. So far it looks to me like there > > is (almost(*)) consensus on not having the console part of the camel > distro. > > > > The contenders are: > > 1. James proposal to move it to the sandbox (as an alternative to my > > subproject suggestoin). I think that's an even better alternative. If > there > > is enough interest it can grow in the sandbox and then we can decide on > its > > future, uhm, future. > > 2. Get rid of it completely (Rob and Dan). > > > > I am in favor of both with a slight bias towards 2. From the thread it's > > not yet clear if the balance tips one way or another, so let's keep the > > discussion going, looks like this will be easy to sort out. > > > > Cheers, > > Hadrian > > > > (*) @cmoulliard: I agree with your point, but it helps way more to sell > > said technology if you had sharp looking eye candy. History indicates > that > > it's not likely to get that from the current camel distro, yet more > likely > > to get it from karaf, hawt.io or other places (ALv2 licensed on top of > > everything). > > > > > > > > On 01/25/2013 06:05 PM, Christian Schneider wrote: > > > >> I think even both may be possible. We could have plugins for apache > >> projects that are written inside the projects or outside. Depending on > >> the interest of a project to build such a plugin and the feasibility to > >> develop it independent of the project release cycle. > >> > >> The core part of my idea is though to have cooporation of multiple > >> organizations and projects towards such a management framework. I think > >> this is too big for one company to succeed on its own and I have seen > >> too many similar projects fail. > >> > >> Christian > >> > >> Am 25.01.2013 23:57, schrieb Guillaume Nodet: > >> > >>> On the other hand, if the plugin is developped outside the Camel > project, > >>> it could be written to support multiple camel versions at the same > time, > >>> especially older versions. Which might be harder (though not > impossible) > >>> if hosted inside camel project itself. > >>> > >>> > >>> On Fri, Jan 25, 2013 at 11:36 PM, Christian Schneider < > >>> ch...@die-schneider.net> wrote: > >>> > >>> > >> > --
