incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Rohr <>
Subject Re: console dev
Date Tue, 01 Jul 2014 17:09:57 GMT

1. Sorry you are correct.  If you have built the UI using the current tools
then the lib directory will be included in the source distro (I understand
the problem there)

2. I want to break down the "extra" tools to do development and provide
reasons why they are there.  If there are ways to simplify or the dev base
doesn't care about the benefits then we can talk about removing the pieces.

    - Ruby - Why do we need ruby on a Java web application?  Right now this
is providing the ability to use Sass (a css precompiler)  The benefit of
this tool is that we can vastly reduce the source needed for styling the
application because it gives us a dynamic css and this tool provides the
concatenation, minification and source maps for the CSS.

    - Bower - This is a Javascript dependency management tool similar to
Maven.  I don't believe installing this manually is required now due to the
Grunt setup, but this downloads external JS dependencies into the lib
folder and the downloads contain all of the files needed to build those
dependencies as well not just the distribution of them.  This is why they
weren't checked in originally.

    - Grunt - The purpose for these tools are it provides us our UI build
system.  Grunt and its plugins give us Javascript concatenation and
minification, asset cache busting, a simple server for UI development with
auto reloading, and most importantly the ability to test the Javascript

    - NodeJs - This is the Javascript runtime that grunt and bower live in
as modules.

I understand the argument about the barrier to entry for this piece of the
code base and I had gone back and forth about this prior to starting the
re-write.  The original contributed blur-console was a Java agent and a
Ruby on Rails front-end itself.  Removing the Ruby dependency isn't a huge
deal though I am not aware of a Java equivalent to Sass.  I did find that
Less does the same thing as Sass (though a slightly different syntax) and
doesn't require Ruby it runs in NodeJs. I believe Bower is not needed
standalone anymore and if requested we could simply include the external JS
dependencies directly in the code base and manually manage them.  Removing
Grunt is a big one and I feel is something we should definitely consider
keeping simply due to the testing aspect that it gives us.

On a separate note, the reason the node_modules directory isn't checked in
and included in the source is two fold.  1. This is equivalent to your
local maven repo and that wouldn't get checked in to source control (it can
get big) and 2. We did find that the assembly jar doesn't work well with
file names that have UTF-8 encoded characters on Linux.  Not sure why that
happens, but the entire build fails.

I really want to build the best management tool for this project that we
can and I want as much help as I can get, so I am totally up for
suggestions going forward.


On Mon, Jun 30, 2014 at 6:04 PM, Tim Williams <> wrote:

> On Mon, Jun 30, 2014 at 4:31 PM, Andrew <> wrote:
> > On Mon, Jun 30, 2014 at 3:20 PM, Tim Williams <>
> wrote:
> >
> >> On Mon, Jun 30, 2014 at 12:31 PM, Chris Rohr <>
> wrote:
> >> > Tim,
> >> >
> >> > Sorry, the README needs to be updated as things have moved around.
>  There
> >> > are a couple of ways to do development on the UI portion of the code
> >> base.
> >> >
> >> > 1. From the src/main/webapp directory run grunt serve which will
> start a
> >> > nodejs server (port 3000 i believe) and serve up the UI and watch for
> JS
> >> > and CSS changes.  This process will also use fake data by default but
> you
> >> > can change that by delete the fakeIt parameter
> >> >
> >> > 2. In eclipse, if you change the source js and scss files you still
> need
> >> to
> >> > run the grunt commands to "compile" into the public directory.  If you
> >> have
> >> > the server running in eclipse, eclipse will NOT auto update the
> running
> >> > system, so you will have to refresh and restart the server on each
> change
> >> > if you want to see it.
> >>
> >> Well, I was going for option 3 - I crafted a bash script that parses
> >> the Gruntfile and uses that to create a new driver file
> >> (index-dev.html) that uses the exploded js files and sits beside the
> >> index.html file.  Sadly, it caused me to realize that we don't seem to
> >> actually ship the sources to these dependencies. With this experience,
> >> I'd like to gently raise a couple questions:
> >>
> >> 1) I think we should be shipping the source code for these js
> >> dependencies with the source distribution vs the 'uglified' stuff
> >> embedded in our uglified js file.  Thoughts?
> >>
> >
> > The source code for the js dependencies is included in the source
> > distribution.
> > The dependencies js can be found in the webapp/libs folder.
> Hmm... on a fresh package, here's the contents of the webapp folder of
> the source tarball - note I don't have a libs folder in there; perhaps
> the packaging got goofed or I'm running it incorrectly?
> twilliams$ ls
> distribution/target/apache-blur-0.2.2-incubating-src/blur-console/src/main/webapp/
> Gruntfile.js
> bower.json
> index.html
> karma.conf.js
> public
> test
> banner
> img
> js
> package.json
> sass
> views
> > The custom js can be found in the webapp/js folder.
> yep, I see the blur-*.js stuffs fine.
> > The console can be "built" from the source distribution (that's why the
> > public folder is included), but it does require some javascript
> development
> > tools to be installed if you wish to make changes.
> Well, that's what I'm asking if we can simplify.  It seems like a lot
> of overhead for to manage 14 external js files to me. My question
> comes at this from the perspective that the typical dev will be a blur
> [java] developer that just wants to add something to the console - the
> higher the barrier of entry, the less likely that would get
> contributed.  But I'm just trying to get a feel for what folks think.
> I tend to work disconnected and that also influences my query as well
> - maven already makes that hard enough.
> --tim

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message