Merge "Added bundle to serve connection manager module"
[dlux.git] / README.md
index 678587c2c3d316ed8e17cd9e69d7c837103d43f5..9c39851ba649ad90a3f37fe17ef2c9e491c1c7c4 100644 (file)
--- a/README.md
+++ b/README.md
-# OpenDaylight DLUX 
-
-OpenDaylight DLUX is a Javascript stateless user interface that communicates with the service backend to provide a consistent and user-friendly interface to interact with OpenDaylight projects and base controller.
-
-
-## Quick Start
-
-Install Node.js then:
-
-```sh
-$ sudo npm -g install grunt-cli karma bower
-$ npm install
-$ bower install
-$ grunt watch
-```
-
-Finally, open `file:///path/to/ng-boilerplate/build/index.html` in your browser.
-
-
-## Overall Directory Structure
-
-At a high level, the structure looks roughly like this:
-
-```
-dlux/
-  |- grunt-tasks/
-  |- karma/
-  |- src/
-  |  |- app/
-  |  |  |- <app logic>
-  |  |- assets/
-  |  |  |- <static files>
-  |  |- common/
-  |  |  |- <reusable code>
-  |  |- less/
-  |  |  |- main.less
-  |- vendor/
-  |  |- angular-bootstrap/
-  |  |- bootstrap/
-  |  |- placeholders/
-  |- .bowerrc
-  |- bower.json
-  |- build.config.js
-  |- Gruntfile.js
-  |- module.prefix
-  |- module.suffix
-  |- package.json
-```
-
-What follows is a brief description of each entry, but most directories contain
-their own `README.md` file with additional documentation, so browse around to
-learn more.
-
-- `karma/` - test configuration.
-- `src/` - our application sources. [Read more &raquo;](src/README.md)
-- `vendor/` - third-party libraries. [Bower](http://bower.io) will install
-  packages here. Anything added to this directory will need to be manually added
-  to `build.config.js` and `karma/karma-unit.js` to be picked up by the build
-  system.
-- `.bowerrc` - the Bower configuration file. This tells Bower to install
-  components into the `vendor/` directory.
-- `bower.json` - this is our project configuration for Bower and it contains the
-  list of Bower dependencies we need.
-- `build.config.js` - our customizable build settings; see "The Build System"
-  below.
-- `Gruntfile.js` - our build script; see "The Build System" below.
-- `module.prefix` and `module.suffix` - our compiled application script is
-  wrapped in these, which by default are used to place the application inside a
-  self-executing anonymous function to ensure no clashes with other libraries.
-- `package.json` - metadata about the app, used by NPM and our build script. Our
-  NPM dependencies are listed here.
-
-
-### The Build System
-
-The best way to learn about the build system is by familiarizing yourself with
-Grunt and then reading through the heavily documented build script,
-`Gruntfile.js`. But you don't need to do that to be very productive with
-`ngBoilerplate`. What follows in this section is a quick introduction to the
-tasks provided and should be plenty to get you started.
-
-The driver of the process is the `delta` multi-task, which watches for file
-changes using `grunt-contrib-watch` and executes one of nine tasks when a file
-changes:
-
-* `delta:gruntfile` - When `Gruntfile.js` changes, this task runs the linter
-  (`jshint`) on that one file and reloads the configuration.
-* `delta:assets` - When any file within `src/assets/` changes, all asset files
-  are copied to `build/assets/`.
-* `delta:html` - When `src/index.html` changes, it is compiled as a Grunt
-  template, so script names, etc., are dynamically replaced with the correct
-  values configured dynamically by Grunt.
-* `delta:less` - When any `*.less` file within `src/` changes, the
-  `src/less/main.less` file is linted and copied into
-  `build/assets/ng-boilerplate.css`.
-* `delta:jssrc` - When any JavaScript file within `src/` that does not end in
-  `.spec.js` changes, all JavaScript sources are linted, all unit tests are run,
-  and the all source files are re-copied to `build/src`.
-* `delta:coffeesrc` - When any `*.coffee` file in `src/` that doesn't match
-  `*.spec.coffee` changes, the Coffee scripts are compiled independently into
-  `build/src` in a structure mirroring where they were in `src/` so it's easy to
-  locate problems. For example, the file
-  `src/common/titleService/titleService.coffee` is compiled to
-  `build/src/common/titleService/titleService.js`.
-* `delta:tpls` - When any `*.tpl.html` file within `src/` changes, all templates
-  are put into strings in a JavaScript file (technically two, one for
-  `src/common/` and another for `src/app/`) that will add the template to
-  AngularJS's
-  [`$templateCache`](http://docs.angularjs.org/api/ng.$templateCache) so
-  template files are part of the initial JavaScript payload and do not require
-  any future XHR.  The template cache files are `build/template-app.js` and
-  `build/template-common.js`.
-* `delta:jsunit` - When any `*.spec.js` file in `src/` changes, the test files
-  are linted and the unit tests are executed.
-* `delta:coffeeunit` - When any `*.spec.coffee` file in `src/` changes, the test
-  files are linted, compiled their tests executed.
-
-As covered in the previous section, `grunt watch` will execute a full build
-up-front and then run any of the aforementioned `delta:*` tasks as needed to
-ensure the fastest possible build. So whenever you're working on your project,
-start with:
-
-```sh
-$ grunt watch
-```
-
-And everything will be done automatically!
-
-### Build vs. Compile
-
-To make the build even faster, tasks are placed into two categories: build and
-compile. The build tasks (like those we've been discussing) are the minimal
-tasks required to run your app during development.
-
-Compile tasks, however, get your app ready for production. The compile tasks
-include concatenation, minification, compression, etc. These tasks take a little
-bit longer to run and are not at all necessary for development so are not called
-automatically during build or watch.
-
-To initiate a full compile, you simply run the default task:
-
-```sh
-$ grunt
-```
-
-This will perform a build and then a compile. The compiled site - ready for
-uploading to the server! - is located in `bin/`, taking a cue from
-traditional software development. To test that your full site works as
-expected, open the `bin/index.html` file in your browser. Voila!
-
-### Live Reload!
-
-DLUX also includes [Live Reload](http://livereload.com/), so you no
-longer have to refresh your page after making changes! You need a Live Reload
-browser plugin for this:
-
-- Chrome - [Chrome Webstore](https://chrome.google.com/webstore/detail/livereload/jnihajbhpnppcggbcgedagnkighmdlei)
-- Firefox - [Download from Live Reload](http://download.livereload.com/2.0.8/LiveReload-2.0.8.xpi)
-- Safari - [Download from Live Reload](http://download.livereload.com/2.0.9/LiveReload-2.0.9.safariextz)
-- Internet Explorer - Surely you jest.
-
-Note that if you're using the Chrome version with `file://` URLs (as is the
-default with `ngBoilerplate`) you need to tell Live Reload to allow it. Go to
-`Menu -> Tools -> Extensions` and check the "Allow access to file URLs" box next
-to the Live Reload plugin.
-
-When you load your page, click the Live Reload icon in your toolbar and
-everything should work magically. w00t!
-
-If you'd prefer to not install a browser extension, then you must add the
-following to the end of the `body` tag in `index.html`:
-
-```html
-<script src="http://localhost:35729/livereload.js"></script>
-```
-
-Boom!
-
+# OpenDaylight DLUX \r
+\r
+OpenDaylight DLUX is a Javascript-based stateless user interface that communicates with the service backend to provide a consistent and user-friendly interface to interact with OpenDaylight projects and base controller.\r
+\r
+\r
+## Quick Start\r
+\r
+1. Install Node.js. Use link http://nodejs.org/download/\r
+2. Go to directory dlux-web from command line\r
+\r
+   $ cd dlux-web\r
+\r
+3. Execute following steps from shell prompt\r
+\r
+   $ sudo npm -g install grunt-cli karma bower\r
+   $ npm install\r
+   $ bower install\r
+\r
+\r
+4. To run the dlux on local node server, use command\r
+\r
+   $ grunt live\r
+\r
+It will start server at http://localhost:9000/. It expects your controller to be running at localhost:8181.\r
+\r
+You can change the base url of controller in file dlux-web/config/development.json\r
+\r
+\r
+5. To generate OSGi bundle for controller, run\r
+\r
+ $ mvn clean install\r
+\r
+It will generate dlux-web-0.1.0-SNAPSHOT.jar under dlux-web/target/.\r
+This assumes that dlux is deployed on same node where md-sal is present. If md-sal is present at different OSGi container,\r
+then you should update the base url in file dlux-web/config/production.json\r
+\r
+6. Copy this jar bundle to plugins directory inside your controller distribution. Then, you can access Dlux UI at http://<<Controller IP>>:8181/dlux/index.html.\r
+\r
+\r
+## Overall Directory Structure\r
+\r
+At a high level, the structure looks roughly like this:\r
+\r
+```\r
+dlux-web/\r
+  |- grunt-tasks/\r
+  |- karma/\r
+  |- src/\r
+  |  |- app/\r
+  |  |  |- <app logic>\r
+  |  |- assets/\r
+  |  |  |- <static files>\r
+  |  |- common/\r
+  |  |  |- <reusable code>\r
+  |  |- less/\r
+  |  |  |- main.less\r
+  |- vendor/\r
+  |  |- angular-bootstrap/\r
+  |  |- bootstrap/\r
+  |  |- placeholders/\r
+  |- .bowerrc\r
+  |- bower.json\r
+  |- build.config.js\r
+  |- Gruntfile.js\r
+  |- module.prefix\r
+  |- module.suffix\r
+  |- package.json\r
+```\r
+\r
+What follows is a brief description of each entry, but most directories contain\r
+their own `README.md` file with additional documentation, so browse around to\r
+learn more.\r
+\r
+- `karma/` - test configuration.\r
+- `src/` - our application sources. [Read more &raquo;](src/README.md)\r
+- `vendor/` - third-party libraries. [Bower](http://bower.io) will install\r
+  packages here. Anything added to this directory will need to be manually added\r
+  to `build.config.js` and `karma/karma-unit.js` to be picked up by the build\r
+  system.\r
+- `.bowerrc` - the Bower configuration file. This tells Bower to install\r
+  components into the `vendor/` directory.\r
+- `bower.json` - this is our project configuration for Bower and it contains the\r
+  list of Bower dependencies we need.\r
+- `build.config.js` - our customizable build settings; see "The Build System"\r
+  below.\r
+- `Gruntfile.js` - our build script; see "The Build System" below.\r
+- `module.prefix` and `module.suffix` - our compiled application script is\r
+  wrapped in these, which by default are used to place the application inside a\r
+  self-executing anonymous function to ensure no clashes with other libraries.\r
+- `package.json` - metadata about the app, used by NPM and our build script. Our\r
+  NPM dependencies are listed here.\r
+\r
+\r
+### The Build System\r
+\r
+The best way to learn about the build system is by familiarizing yourself with\r
+Grunt and then reading through the heavily documented build script,\r
+`Gruntfile.js`. But you don't need to do that to be very productive with\r
+`ngBoilerplate`. What follows in this section is a quick introduction to the\r
+tasks provided and should be plenty to get you started.\r
+\r
+The driver of the process is the `delta` multi-task, which watches for file\r
+changes using `grunt-contrib-watch` and executes one of nine tasks when a file\r
+changes:\r
+\r
+* `delta:gruntfile` - When `Gruntfile.js` changes, this task runs the linter\r
+  (`jshint`) on that one file and reloads the configuration.\r
+* `delta:assets` - When any file within `src/assets/` changes, all asset files\r
+  are copied to `build/assets/`.\r
+* `delta:html` - When `src/index.html` changes, it is compiled as a Grunt\r
+  template, so script names, etc., are dynamically replaced with the correct\r
+  values configured dynamically by Grunt.\r
+* `delta:less` - When any `*.less` file within `src/` changes, the\r
+  `src/less/main.less` file is linted and copied into\r
+  `build/assets/ng-boilerplate.css`.\r
+* `delta:jssrc` - When any JavaScript file within `src/` that does not end in\r
+  `.spec.js` changes, all JavaScript sources are linted, all unit tests are run,\r
+  and the all source files are re-copied to `build/src`.\r
+* `delta:coffeesrc` - When any `*.coffee` file in `src/` that doesn't match\r
+  `*.spec.coffee` changes, the Coffee scripts are compiled independently into\r
+  `build/src` in a structure mirroring where they were in `src/` so it's easy to\r
+  locate problems. For example, the file\r
+  `src/common/titleService/titleService.coffee` is compiled to\r
+  `build/src/common/titleService/titleService.js`.\r
+* `delta:tpls` - When any `*.tpl.html` file within `src/` changes, all templates\r
+  are put into strings in a JavaScript file (technically two, one for\r
+  `src/common/` and another for `src/app/`) that will add the template to\r
+  AngularJS's\r
+  [`$templateCache`](http://docs.angularjs.org/api/ng.$templateCache) so\r
+  template files are part of the initial JavaScript payload and do not require\r
+  any future XHR.  The template cache files are `build/template-app.js` and\r
+  `build/template-common.js`.\r
+* `delta:jsunit` - When any `*.spec.js` file in `src/` changes, the test files\r
+  are linted and the unit tests are executed.\r
+* `delta:coffeeunit` - When any `*.spec.coffee` file in `src/` changes, the test\r
+  files are linted, compiled their tests executed.\r
+\r
+As covered in the previous section, `grunt watch` will execute a full build\r
+up-front and then run any of the aforementioned `delta:*` tasks as needed to\r
+ensure the fastest possible build. So whenever you're working on your project,\r
+start with:\r
+\r
+```sh\r
+$ grunt watch\r
+```\r
+\r
+And everything will be done automatically!\r
+\r
+### Build vs. Compile\r
+\r
+To make the build even faster, tasks are placed into two categories: build and\r
+compile. The build tasks (like those we've been discussing) are the minimal\r
+tasks required to run your app during development. Build use developement.json for configuration.\r
+\r
+Compile tasks, however, get your app ready for production. The compile tasks\r
+include concatenation, minification, compression, etc. These tasks take a little\r
+bit longer to run and are not at all necessary for development so are not called\r
+automatically during build or watch. Compile use production.json as configuration file.\r
+\r
+To initiate a full compile, you simply run the default task:\r
+\r
+```sh\r
+$ grunt\r
+```\r
+\r
+This will perform a build and then a compile. The compiled site - ready for\r
+uploading to the server! - is located in `src/main/resources/pages`, taking a cue from\r
+traditional software development. To test that your full site works as\r
+expected, open the `src/main/resources/pages/index.html` file in your browser. Voila!\r
+\r
+### Maven Build\r
+\r
+Maven is added to generate an OSGi compatible bundle that can be shipped with Opendaylight Controller.\r
+Maven internally runs grunt production ready build and generate a jar out of it.\r
+Once you successfully run 'mvn clean install', the OSGi bundle jar gets generated under target/.\r
+### Live Reload!\r
+\r
+DLUX also includes [Live Reload](http://livereload.com/), so you no\r
+longer have to refresh your page after making changes! You need a Live Reload\r
+browser plugin for this:\r
+\r
+- Chrome - [Chrome Webstore](https://chrome.google.com/webstore/detail/livereload/jnihajbhpnppcggbcgedagnkighmdlei)\r
+- Firefox - [Download from Live Reload](http://download.livereload.com/2.0.8/LiveReload-2.0.8.xpi)\r
+- Safari - [Download from Live Reload](http://download.livereload.com/2.0.9/LiveReload-2.0.9.safariextz)\r
+- Internet Explorer - Surely you jest.\r
+\r
+Note that if you're using the Chrome version with `file://` URLs (as is the\r
+default with `ngBoilerplate`) you need to tell Live Reload to allow it. Go to\r
+`Menu -> Tools -> Extensions` and check the "Allow access to file URLs" box next\r
+to the Live Reload plugin.\r
+\r
+When you load your page, click the Live Reload icon in your toolbar and\r
+everything should work magically. w00t!\r
+\r
+If you'd prefer to not install a browser extension, then you must add the\r
+following to the end of the `body` tag in `index.html`:\r
+\r
+```html\r
+<script src="http://localhost:35729/livereload.js"></script>\r
+```\r
+\r
+Boom!\r
+\r
+### Testing\r
+\r
+Tests can be run via grunt-watch command. It opens separate Chrome instance for running tests. This instance need to be open\r
+at all times (or at least during the time you want tests to be executed). Note on test execution speed - Chrome is at lower CPU \r
+priority when minimalized, or tab where are test executed is not active. This grealy decreases test execution speed, so in that \r
+case, just bring up the Chrome and/or activate tab with tests. Test are executed every time on Grunt jshint command.\r
+\r
+If you want to create/alter new task or command in Gruntfile and want to plug in test execution, you can add karma:unit to new \r
+Grunt task or karma:unit:run to Grunt command.\r
+\r
+If you are writing tests, they should be in same folder as tested file in form <TESTED_FILE>.spec.js\r