2:31 p.m.
On 27 Jan 2015, at 11:05, Thomas Heute <theute(a)redhat.com>
wrote:
On 01/27/2015 06:09 PM, Viliam Rockai wrote:
> Hey All,
>
> I want to start this thread to gather some information about how
> components are shared between projects. So, to make the terminology
> clear, lets check this stuff:
> https://github.com/vrockai/hawkular/tree/master/ui/console/alerts
> https://github.com/vrockai/hawkular/tree/master/ui/console/metrics
>
> are future components/widgets which are going to be used on the console
> page. Those components are Hawtio 2.x plugins.
>
> According to:
> https://github.com/hawtio/hawtio/blob/master/docs/Overview2dotX.md
>
> I expect exposing plugins as bower packages is the preferred way in
> Hawtio 2.x. From my perspective (angular guy) this is pretty much what
> is expected. The only way to expose/share those components as bower
> packages to third-parties would be to put them in separate repo. As was
> already said on IRC, this may be overkill. I see two ways of resolution:
>
> 1. Create separate repository for each component. Those all would be
> bower dependencies of the hawkular console.
> Pros: possibly consistent with the Hawtio 2.x ways, modularity = we
> download only what we need.
> Cons: lots of repositories to take care of.
>
> 2. Create a single repository for all the plugins. The whole library of
> sibling components, similar to i.e. Angular-UI.
> Pros: easier maintenance.
> Cons: less modular = need to download whole library before we filter
> which plugins we want to use.
>
> I see, that the 2nd approach already exists in the hawtio repository,
> probably the best way would be to put our components to this repo:
> https://github.com/hawtio/hawtio-ui
We need to be able to release early/often and be relatively independent.
I don't think our components are generic enough for this repository
anyway (since they depend on our services).
It's a long term goal to be able to consume Fabric8 hawt.io plugin and
to be embeddable with OpenShift Dev console but in the immediate the
priority is to have a standalone monitoring project. In the short/medium
term we will anyway only build plugins that we need for hawkular so the
cons of having to download the whole library doesn't really apply. I
don't know anything about Bower/hawt.io and UI stuff of 2014/2015 but
option 2 sounds good at least initially while we need to develop fast
and will likely want to reorg code a couple of times before we are
satisfied.
I notice that they have a single repo for multiple plugins so I guess we
can as well ?
Perhaps you are looking at the old plugins some of which have not
been migrated to the new hawt.io 2 plugin architecture. Right now there are 11 bower
packages(and corresponding repos):
http://bower.io/search/?q=hawtio <http://bower.io/search/?q=hawtio>
Plugins are bower packages and require a git repo but several plugins can be packaged into
a single bower package.
So that sounds like our best bet to add another git repo for the ui and wrap all of our
plugins up into that bower package.
Thomas
Thomas
>
> Thanks for your thoughts,
>
> Viliam
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org <mailto:hawkular-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
<https://lists.jboss.org/mailman/listinfo/hawkular-dev>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org <mailto:hawkular-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hawkular-dev
<https://lists.jboss.org/mailman/listinfo/hawkular-dev>