... and to make it precise. By writing "fighting for it" I mean: - add missing features to Karaf WebConsole - provide better documentation (for users and developers) - make it as easy as possible to install it - and whatever you can do to improve Karaf WebConsole.
Best, Christian On Sun, Jan 27, 2013 at 6:55 PM, Christian Müller < christian.muel...@gmail.com> wrote: > Hi Lukasz! > > I also do not see any issues with this announcement on the dev@ Camel > mailing list. > This announcement is relevant for the Camel users as it offers a awesome > management user interface for Camel (and other frameworks/technologies). > Even better, this product is also open source under Apache license 2.0. > This announcement is NOT spam. > > Also the fact that this project is not an Apache project is NOT an issue > at all. As the others already mentioned, we use multiple > projects/frameworks which are developed outside the Apache community. What > would we do if we couldn't use great frameworks/products like Spring, > Jetty, JUnit, Pax-*, EasyMock, Quartz, ... or Jolokia? > > I share Guillaumes opinion that your post sounds angry. But I think there > is really no reason for. If this product is in competition with an existing > (Apache) project like Karaf WebConsole, this is a good thing from my point > of view. Competition creates great products and is powering progress. And > at the end, *IF* one of the projects will disappear because their user > basis is getting to small, than because the user decided to use the other - > better - tool. It's not nice to see dieing a project. It's even harder if > it's a project you are involved with. But that's life and also has goods. > But until now, Karaf WebConsole is alive and you can try to convince your > users that this is the better web console for Karaf and Camel. Go out and > fight for it! > > Have a nice - not so cold - week, > Christian > > > On Sat, Jan 26, 2013 at 3:11 PM, Jean-Baptiste Onofré > <j...@nanthrax.net>wrote: > >> Hi Lukasz, >> >> I don't see any issue or spam in Guillaume's e-mail: he shared an >> information with multiple communities, as it considers (and I think he's >> right) that the information has value and interest for those communities. >> Apache is not a technical project hosting, it's a set of project >> communities. Like in all communities, we are here to share ideas and >> discuss in a fair, smart, and kind way. >> In Karaf (and other projects), we already discussed and use projects >> coming from "outside". It's long list: Cellar, EIK, Pax*, jledit, etc. >> I remember to have send a couple of e-mails to inform Karaf community >> about new projects that may interest us (Pax-CDI and Pax-JDBC for instance). >> >> Regards >> JB >> >> >> On 01/25/2013 08:12 PM, Łukasz Dywicki wrote: >> >>> Guillaume, >>> If I'll send a mail with announcement about my amazing project, whatever >>> it will be, to apache mailing lists I will be treat a spamer. If I will try >>> doing that with more mailing lists - then I'll be treat as spamer - that's >>> for sure. And that's what have you done. You have something which relates >>> to Apache projects but it's not Apache project yet. Apache mailing lists >>> are not for announcement about products and projects which are not made >>> under Apache Foundation. Please honor that. >>> >>> That's all in this topic from me and I don't going to discuss about any >>> other Fuse project any more on Apache mailing lists. If you want donate >>> hawt.io, that's fine - write incubator proposal (as it doesn't fit >>> Karaf at all) or take it as part of other community. I don't care. >>> For example you may wish use ServiceMix for that. You have most of >>> commiters there. It will fit also SMX5, more over it will let you >>> resuscitate it after two years of doing nothing. >>> >>> I hope I made it clear. >>> -- >>> Cheers from cold Poland, >>> Lukasz >>> >>> Wiadomość napisana przez Guillaume Nodet <gno...@gmail.com> w dniu 25 >>> sty 2013, o godz. 19:22: >>> >>> As I explained in the camel thread, I think the main benefit and >>>> difference >>>> is that hawtio is not OSGi at all. It can work in OSGi but is not tied >>>> or >>>> linked to it in anyway. It means the plugins can be reused for non OSGi >>>> users, which still represent a big part of the camel and activemq user >>>> base. >>>> The idea would be to avoid having each project needing a different web >>>> console at the end (and those projects can't really use the Karaf one I >>>> think). >>>> For Karaf, we don't really care, but the downstream projects do, and >>>> aligning on something would help working together on the same code base. >>>> >>>> i don't honestly care about the location of the project itself. We >>>> depends >>>> on lots of things that are not hosted at the ASF (all the pax stuff for >>>> example) and that has never been a problem. And I don't really think >>>> this console belongs to Karaf at all because it's not OSGi related. It >>>> would actually be an adoption problem for hawtio if it would be in >>>> Karaf as >>>> it would be seen as being OSGi, even if it's not. Besides that, I doubt >>>> James is willing to move it anywhere else atm. >>>> >>>> For now, given the project is not really mature, I think the best way >>>> going >>>> forward is to start hacking plugins inside that project itself and we'll >>>> see over time how it evolves. If there's a need to move each plugin >>>> back >>>> to the original project, it can be done, but today is really not the >>>> day to >>>> think about that imho, that's a minor issue, and as long as people are >>>> able >>>> to hack on plugins, it should be ok. For this purpose,, github (with >>>> forks and pull requests) is actually much easier than the ASF. >>>> >>>> If the hawtio project really picks up, then switching to it can be >>>> considered, but we may want it to mature a bit more before. Im sure >>>> it's >>>> still missing a lot of features we may need, and I only had a quick >>>> look at >>>> it, but I really like the underlying technology (a static html page, >>>> REST >>>> for accessing the backend, and the whole JMX tree being available >>>> through >>>> REST with jolokia). >>>> >>>> >>>> >>>> >>>> On Fri, Jan 25, 2013 at 7:01 PM, Jean-Baptiste Onofré <j...@nanthrax.net >>>> >wrote: >>>> >>>> AFAIR (I think that Lukasz and Achim will jump in), once again, it's >>>>> exactly the purpose of Karaf WebConsole: provide a kind of container >>>>> for >>>>> plugins/features extensions. >>>>> >>>>> That's my point: identify the overlap/gap between Karaf WebConsole and >>>>> HawtIO to "communicate" and anticipate the adoption. >>>>> IMHO, as ActiveMQ, ServiceMix, Karaf, Camel, KarafEE, etc are Apache >>>>> projects, it would make sense to have the "Console" project at Apache. >>>>> As a >>>>> Karaf subproject, we can move forward and see later if it makes sense >>>>> to >>>>> promote as a TLP. >>>>> >>>>> My $0.02 >>>>> >>>>> Regards >>>>> JB >>>>> >>>>> >>>>> On 01/25/2013 06:22 PM, Christian Schneider wrote: >>>>> >>>>> I have not looked into HawtIO in detail but the idea of having a >>>>>> general >>>>>> console with plugins for each technology sounds good to me. >>>>>> I also think it is good to start such a console separately in github >>>>>> as >>>>>> it allows for fast progress to show it works. >>>>>> >>>>>> For the long term I think that the generic part of such a console >>>>>> should >>>>>> move into an apache project. As it makes sense to keep the console >>>>>> independent of OSGi a separate project may make sense. >>>>>> So why should we do this in apache? The reason is that currently >>>>>> HawtIO >>>>>> is just another console. Only at a big community like apache we can >>>>>> hope >>>>>> for a project to get enough acceptance that a lot of projects >>>>>> participate. >>>>>> >>>>>> So if we succeed in creating an accepted generic foundation for >>>>>> management consoles then each of the technology plugins could be >>>>>> developed in the respective projects. >>>>>> >>>>>> What do you think about this? >>>>>> >>>>>> Christian >>>>>> >>>>>> On 25.01.2013 12:08, Guillaume Nodet wrote: >>>>>> >>>>>> FYI, I'm really excited about finally being able to have a unified >>>>>>> web >>>>>>> console for Karaf / ActiveMQ / Camel, especially the fact that the >>>>>>> same >>>>>>> web >>>>>>> console can be used in a non OSGi-environment, so we can really >>>>>>> leverage >>>>>>> and work together on a single web console. >>>>>>> I'd encourage everyone to have a look at it and eventually look at >>>>>>> what's >>>>>>> missing from a Karaf point of view so that we can discuss if/how we >>>>>>> integrate it. >>>>>>> >>>>>>> ---------- Forwarded message ---------- >>>>>>> From: James Strachan <james.strac...@gmail.com> >>>>>>> Date: Fri, Jan 25, 2013 at 10:59 AM >>>>>>> Subject: [ANN] hawtio: a new lightweight HTML5 console for Apache >>>>>>> Camel, >>>>>>> ActiveMQ, JMX, OSGi & Fuse Fabric >>>>>>> To: "us...@camel.apache.org" <us...@camel.apache.org> >>>>>>> >>>>>>> >>>>>>> For the impatient just look here :) http://hawt.io/ >>>>>>> >>>>>>> Background >>>>>>> ========== >>>>>>> We've had numerous consoles all over the place for some time in >>>>>>> various projects like Felix, Karaf, ActiveMQ, Camel, Tomcat, Fuse >>>>>>> Fabric to name but a few. Many of them quite heavy weight requiring a >>>>>>> custom web app to be deployed (which often is quite large); none >>>>>>> particularly working together. >>>>>>> >>>>>>> We've been working on Fuse Fabric and its management console to >>>>>>> provide a more consolidated view of a cluster of Apache integration & >>>>>>> middleware technologies. Increasingly we're seeing our users and >>>>>>> customers using different combinations of technologies in different >>>>>>> containers (e.g. Tomcat + ActiveMQ or Karaf + Camel or Fuse Fabric + >>>>>>> Karaf + ActiveMQ + Camel or whatever). >>>>>>> >>>>>>> So for a few months a few of us have been working on trying to make >>>>>>> the various web consoles for things like Apache Camel, ActiveMQ, >>>>>>> Felix/Karaf/OSGi & Fuse Fabric (long with more generic things like >>>>>>> JMX >>>>>>> & OSGi) available as lightweight HTML5 plugins so they can be mixed >>>>>>> and matched together to suite any container and combination of >>>>>>> technologies that folks deploy in a JVM. >>>>>>> >>>>>>> >>>>>>> hawtio >>>>>>> ===== >>>>>>> The result so far is hawtio: http://hawt.io/ >>>>>>> >>>>>>> You can deploy it as a WAR in any JVM (or feature in karaf) and it >>>>>>> provides a UI console for whatever it finds in the JVM. So it works >>>>>>> with Tomcat / Jetty / Karaf / JBoss / Fuse Fabric; and has plugins >>>>>>> for >>>>>>> JMX, OSGi, ActiveMQ, Camel & Fuse Fabric so far with others on the >>>>>>> way. >>>>>>> >>>>>>> The nice thing is its pretty small (about 1Mb WAR containing all the >>>>>>> server side code, HTML, JS, images, CSS etc). The only real server >>>>>>> side component is jolokia which is a small (about 300K) REST >>>>>>> connector >>>>>>> for JMX (which is awesome BTW!) - the rest is static content (which >>>>>>> could be served from anywhere so doesn't need to be deployed in each >>>>>>> JVM). >>>>>>> >>>>>>> Its based around a plugin architecture: >>>>>>> http://hawt.io/developers/****plugins.html<http://hawt.io/developers/**plugins.html> >>>>>>> <http://hawt.io/**developers/plugins.html<http://hawt.io/developers/plugins.html> >>>>>>> > >>>>>>> >>>>>>> so its easy to add new plugins for any kind of technology. A plugin >>>>>>> is >>>>>>> pretty much anything that runs in a browser. >>>>>>> >>>>>>> The nice thing is hawtio can discover UI plugins at runtime by >>>>>>> examining the contents of the JVM or querying REST endpoints; so the >>>>>>> UI can update in real time as you deploy new things into a JVM! >>>>>>> >>>>>>> >>>>>>> hawtio, the hawt camel rider >>>>>>> ====================== >>>>>>> A quick summary of the current features for camel folks: >>>>>>> >>>>>>> * If you have any camel contexts running in a JVM when hawtio starts >>>>>>> up it adds an Integration tab which shows all the camel contexts >>>>>>> running. >>>>>>> >>>>>>> * You can start/stop/suspend/resume the context and its routes; then >>>>>>> look at all the metrics for routes/endpoints/processors. The Charts >>>>>>> tab lets you visualise the real time metrics. >>>>>>> >>>>>>> * You can create new endpoints; browse endpoints which are browsable >>>>>>> & >>>>>>> send messages to endpoints (with syntax editing support for JSON / >>>>>>> XML >>>>>>> / YAML / properties) >>>>>>> >>>>>>> * You can visualise all the camel routes or a specific camel route >>>>>>> for >>>>>>> a context in the Diagram tab and see real time metrics of how many >>>>>>> messages are passing through each step on the diagram. e.g. >>>>>>> https://raw.github.com/hawtio/****hawtio/master/website/src/**<https://raw.github.com/hawtio/**hawtio/master/website/src/**> >>>>>>> images/screenshots/camelRoute.****png<https://raw.github.com/** >>>>>>> hawtio/hawtio/master/website/**src/images/screenshots/** >>>>>>> camelRoute.png<https://raw.github.com/hawtio/hawtio/master/website/src/images/screenshots/camelRoute.png> >>>>>>> > >>>>>>> >>>>>>> * Clicking on a Route allows you to Trace it; when tracing if you >>>>>>> send >>>>>>> a message into a route then it captures a copy of the message at each >>>>>>> point through the route. So you can step through (scroll/click >>>>>>> through >>>>>>> the table) a route and see the message contents and how the message >>>>>>> flows through the EIPs - highlighting where on the diagram each >>>>>>> message is. This is very handy for figuring out why your route >>>>>>> doesn't >>>>>>> work :) Spot where the heading disappears! Or see why the CBR doesn't >>>>>>> go where you expected. >>>>>>> >>>>>>> In general most of the runtime features of the open source Fuse IDE >>>>>>> eclipse tooling are now supported in the camel hawtio plugin; so >>>>>>> available in a web browser. >>>>>>> >>>>>>> >>>>>>> Summary >>>>>>> ======= >>>>>>> So if you're vaguely interested in web consoles for Apache Camel I >>>>>>> urge you to give it a try. We love contributions and feedback! >>>>>>> http://hawt.io/contributing/****index.html<http://hawt.io/contributing/**index.html> >>>>>>> <http://hawt.io/**contributing/index.html<http://hawt.io/contributing/index.html> >>>>>>> > >>>>>>> >>>>>>> or feel free to raise new issues for how to improve the camel plugin: >>>>>>> https://github.com/hawtio/****hawtio/issues?labels=camel&**<https://github.com/hawtio/**hawtio/issues?labels=camel&**> >>>>>>> page=1&sort=updated&state=**open<https://github.com/** >>>>>>> hawtio/hawtio/issues?labels=**camel&page=1&sort=updated&**state=open<https://github.com/hawtio/hawtio/issues?labels=camel&page=1&sort=updated&state=open> >>>>>>> > >>>>>>> >>>>>>> or if you've an itch for a new kind of plugin please dive in! We >>>>>>> should be able to expose existing web apps/consoles as links inside >>>>>>> hawtio too BTW. >>>>>>> >>>>>>> Feedback appreciated! Its hawt, but stay cool! ;) >>>>>>> >>>>>>> -- >>>>>>> James >>>>>>> ------- >>>>>>> Red Hat >>>>>>> >>>>>>> Email: jstra...@redhat.com >>>>>>> Web: http://fusesource.com >>>>>>> Twitter: jstrachan, fusenews >>>>>>> Blog: http://macstrac.blogspot.com/ >>>>>>> >>>>>>> Open Source Integration >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>> Jean-Baptiste Onofré >>>>> jbono...@apache.org >>>>> http://blog.nanthrax.net >>>>> Talend - http://www.talend.com >>>>> >>>>> >>>> >>>> >>>> -- >>>> ------------------------ >>>> Guillaume Nodet >>>> ------------------------ >>>> Red Hat, Open Source Integration >>>> >>>> Email: gno...@redhat.com >>>> Web: http://fusesource.com >>>> Blog: http://gnodet.blogspot.com/ >>>> >>> >>> >> -- >> Jean-Baptiste Onofré >> jbono...@apache.org >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> > > > > -- > > --
