On Dec 4, 2014, at 10:03 PM, mike thompson <mithomps@redhat.com> wrote:


On 4 Dec 2014, at 18:35, John Sanda <jsanda@redhat.com> wrote:

On Dec 4, 2014, at 8:46 PM, mike thompson <mithomps@redhat.com> wrote:

Here is the second video in the three part series about Bower package management.

This video focuses on package conflict resolution in bower:


The next and last in the series(although there will probably some tips/tricks videos), is a video on publishing and registering your own bower packages(hint: its easier than maven).

IMO, bower is nice, lightweight, focused solution to front-end asset management involving javascript, css, images and other UI assets(not just Angular). It allows easy versioning, deployment and transitive dependency management for JS UIs.

I have not watched the videos yet, but I do have one question. Since we we have separate build tools for UI assets, would it be better/easier to put the those UI pieces in their own separate project instead of wrapping them with the maven build as we currently do?

It’s subjective. Its a UI just for rhq-metrics so my tendency is that it probably should be in rhq-metrics. But, if we want to split the project into other pieces, it might make sense. Same question could be asked of clients(i.e., ptrans). Its not part of core but associated with the project and their could be many different adapters. The UI is not part of core but is associated only with this project. If we look at other projects, it is not normal that UIs are their own project so my guess is no.  Just depends at what granularity  we want for the repos. BTW, the charting package has just been split to its own repo because it could be used across many other projects (and bower packages require their own repo).



I was not necessarily suggesting a separate project as in a separate repo. And absolutely yes, the same question could be asked of the other clients. But to make a more accurate analogy, suppose I decide to write a client in python. I might use distutils for creating/configure my module(s). I wouldn’t want wrap that in the maven build, but I might want to keep it in the same git repo. Maybe something like,

rhq-metrics
|
|—— build.sh
|
|—— java-clients
|
|—— server
|
|—— python-client
|
|—— js-ui-client

The directory illustrates what I had in mind. The JS UI client would be pulled into the WAR just like any other external dependency. Then we could have an uber build shell script (if necessary) which is just a small wrapper around the various builds. To be clear, I am not suggesting putting a whole bunch of build logic into a shell script. I am asking though, would it be easier and better to separate other build/packaging tools instead of wrapping them with maven. It would be a lot easier to tie things together with a simple shell script. Way back in the day when I worked on RHN this is similar to how things were set up. There was a single svn repo for the project, and we had java, python, and perl bits.