Will have a look at hawtio over the weekend... This thread has to cool down bit. Looking for technical discussions and proposals how to move forward.
Best, Christian Sent from a mobile device Am 25.01.2013 22:30 schrieb "Guillaume Nodet" <[email protected]>: > On Fri, Jan 25, 2013 at 8:12 PM, Łukasz Dywicki <[email protected]> > 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. > > > It's not even MY project. James only talked about it to me a few days ago > and I have never committed anything to it, go check the log if you want. > > Such a person would be a spammer if it keeps sending out-of-topic emails > for no reason. Do I have to remind you that James sent that annoucement > email because I mentioned this project on the mailing list a few hours > before, just saying we could have a look at it. It was relevant to the > discussion, because we were talking about the future web console for Camel > 3. People started talking about hawtio, so it totally made sense for > James to start a separate thread about it instead of polluting the camel 3 > discussion and give a few explanations about what hawtio is. When we talk > about web console, talking about web console technologies is not really > spamming to me. It's just technical discussion. > > So no, if you're start a project outside the ASF that could be beneficial > for the project, you really should talk about it. Not doing that is a > disservice to the project and the community. > > > > You have something which relates to Apache projects but it's not Apache > > project yet. > > > It may not even become an ASF project, nobody ever talked about that. So I > really don't get the "yet" part. Really, I don't. > > > > Apache mailing lists are not for announcement about products and > projects > > which are not made under Apache Foundation. Please honor that. > > > > Well, then you don't understand what the ASF is. It's not a silo with a a > rule enforcement about not talking about other projects, not using them, or > enforcing solely the use of other ASF projects. Remember the mantra > "community over code" ? The ASF is about community. The ASF does not have > any technical steering committee does not forbid competing projects inside > the ASF (there are a bunch of those already). An ASF projects is free to > use whatever other project it wishes, as long as the license is compatible > with ASL. > > For example, we do use a lot of pax stuff (logging, web, etc..) which some > of us are heavily involved in. Some of us are also involved in other > projets that we use which come from the ASF (mina, felix, aries). We're > also using jetty and not tomcat (where none of us is really involved in), > so what's your point ? Some very good projects are developped outside the > ASF. ASF is one style of open-source development, it's not either the only > one, nor does it have to be. > > If we can't discuss and disagree over things in a calm way, then there's a > problem, for sure. > > > > 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. > > > We're not discussing a Fuse project. James starts all kind of projects > each year. Some of them are good and pick up, some of them don't. We > talked about this project because it makes sense for the communities and > projects here at the ASF. Forbidding to talk about it is just nonsense. > > If you want another example, I'm currently trying to have weld-osgi, the > cdi container, running correctly in OSGi and Karaf. It's not an ASF > project, and the discussion about CDI never came up on Karaf dev list. > Would it have been the case, I would have talked about what I'm doing. > And that would have been relevant. Another thing I have in mind is to > upgrade to OSGi r5 at some point in the future, and I may look at the > repository implementation David B wrote in jboss-osgi to see if it fits my > needs. If it does not, I'll intend to either modify it if I think it's > doable, or even rewrite a new one if I think it makes more sense. Is that > also a crime for you ? > > > > 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. > > > But nobody talked about donating hawtio anywhere at this point. I even > said a few hours ago I don't think it's a good idea, at least at the > moment. I don't really have any saying in this anymore, given I haven't > even touched it. > > > > For example you may wish use ServiceMix for that. You have most of > > committers there. It will fit also SMX5, more over it will let you > > resuscitate it after two years of doing nothing. > > > > Not sure I get your point here. Should I be ashamed of not having worked a > lot on ServiceMix recently after having worked mostly full time on it for 5 > years ? You must be kidding, right ? Anyway, no ASF committer is bound to > a project and the people are free to work or not work on anything they > want. The value of ServiceMix went away, first when Camel was created, > then when the Kernel was moved to a TLP in Karaf. Everyone knows that, > even if it took time to admit it. And btw, I don't see how hawtio would > fit in ServiceMix at all. Fwiw, I don't think it fits in any TLP I can > think of right now. Again, everything does not *have to* be at the ASF: > the ASF does not try to rule the world. > > > > I hope I made it clear. > > > > No, not really. And that time, I hope nobody is accusing James or me to > try to push a hidden company agenda : do I have to remind you that you and > I are actually working for the same company ? Maybe the problem is there > has been very few hot technical discussions in the projects we've worked > at. > > Anyway, this email is pointless and too much time consuming for me (I'm > usually spending a *lot* of time writing such emails to make sure I won't > regret a single word of it, which does not always succeed btw). So please, > have a break during the weekend, stop attacking people and if you have > technical arguments, raise them so that we can get the discussion going > with sane arguments. > > -- > > Cheers from cold Poland, > > Lukasz > > > > Wiadomość napisana przez Guillaume Nodet <[email protected]> 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é <[email protected] > > >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 <[email protected]> > > >>>> 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: "[email protected]" <[email protected]> > > >>>> > > >>>> > > >>>> 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> > > >>>> > > >>>> 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/** > > >>>> 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> > > >>>> > > >>>> or feel free to raise new issues for how to improve the camel > plugin: > > >>>> 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: [email protected] > > >>>> Web: http://fusesource.com > > >>>> Twitter: jstrachan, fusenews > > >>>> Blog: http://macstrac.blogspot.com/ > > >>>> > > >>>> Open Source Integration > > >>>> > > >>>> > > >>>> > > >>>> > > >>> > > >>> > > >> -- > > >> Jean-Baptiste Onofré > > >> [email protected] > > >> http://blog.nanthrax.net > > >> Talend - http://www.talend.com > > >> > > > > > > > > > > > > -- > > > ------------------------ > > > Guillaume Nodet > > > ------------------------ > > > Red Hat, Open Source Integration > > > > > > Email: [email protected] > > > Web: http://fusesource.com > > > Blog: http://gnodet.blogspot.com/ > > > > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Red Hat, Open Source Integration > > Email: [email protected] > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ >
