On 27 Jan 2015, at 09:09, Viliam Rockai <vrockai(a)redhat.com&gt; 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 Thanks for your thoughts, Viliam _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

On 27 Jan 2015, at 09:51, Viliam Rockai <vrockai(a)redhat.com&gt; wrote: On Tue, 2015-01-27 at 09:25 -0800, mike thompson wrote: >> On 27 Jan 2015, at 09:09, Viliam Rockai <vrockai(a)redhat.com&gt; 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. > > We could use a combination of 1 + 2 meaning: use the directory structure of 2, but publishing each of those plugins as bower components to pulled into the main Hawkular-console (or other hawt.io consoles). This keeps the plugins free of maven as only the Hawkular console build would use maven to pull in the bower components. Each plugin publishes a new version when ready and Hawkular console can assemble using whatever versions. > Pros: easier maintenance, code is all in one place. We get bower components and versioning. > Cons: there is no need for a target directory (because no maven for ui plugins) so bower/npm component artefacts get downloaded into source dir. > I don't understand, can you please show it on some example directory structure? Do you mean to have number of directories (one for each plugin) with bower.json in each directory? I'm confused, because bower package == repository. I can't publish a plugin within a repository. Once published, it's the whole repository which is published, not just one sub-directory in it.

Bower and npm stuff in the src directory: In the LO console we wanted to avoid this. The idea was, once you do "mvn clean" you should have the same files as before the build and everything else is deleted. Using .gitignore for special node/bower directories may be obvious to people developing the console, but may cause some pain to people who expect the src not to contain anything new (cached packages, which are not updated, ...) after cleaning. But if it's not a maven project, I don't think this applies. If this is only a case for the "bower package" repository of our plugins, I don't see it as a con.

> >> >> 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 >> >> Thanks for your thoughts, >> >> Viliam

>> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >

On 27 Jan 2015, at 11:05, Thomas Heute <theute(a)redhat.com&gt; 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 ?

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>

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/27/2015 06:09 PM, Viliam Rockai wrote: > 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. I'd go with this one, coupled with a good CI mechanism. For Jenkins, you could have "pipes" and a "release" plugin, so, if the modules are independent enough, releasing should not take an effort bigger than clicking on a button (if that's what you mean by "lots of repositories to take care of").

- - Juca. _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev