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):
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.