[Hawkular-dev] Console project structure and plugins

[mike thompson]

> On 27 Jan 2015, at 11:05, Thomas Heute <theute at 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 at lists.jboss.org <mailto:hawkular-dev at 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 at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hawkular-dev <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150127/df29b9c9/attachment-0001.html