karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric
Date Fri, 25 Jan 2013 21:30:16 GMT
On Fri, Jan 25, 2013 at 8:12 PM, Łukasz Dywicki <luke@code-house.org> 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 <gnodet@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é <jb@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.strachan@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: "users@camel.apache.org" <users@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>
> >>>>
> >>>> 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: jstracha@redhat.com
> >>>> Web: http://fusesource.com
> >>>> Twitter: jstrachan, fusenews
> >>>> Blog: http://macstrac.blogspot.com/
> >>>>
> >>>> Open Source Integration
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >> --
> >> Jean-Baptiste Onofré
> >> jbonofre@apache.org
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >>
> >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> > ------------------------
> > Red Hat, Open Source Integration
> >
> > Email: gnodet@redhat.com
> > Web: http://fusesource.com
> > Blog: http://gnodet.blogspot.com/
>
>


-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message