Monday, January 26, 2015

Vert.x with gulp.js

Vert.x is often put forward as a polyglot alternative to node.js that runs on the JVM. A read through the vert.x javascript docs indicates that javascript is a first-class language in vert.x, and both node.js and vert.x use an event-driven, non-blocking I/O programming model. But to what degree will a node programmer feel at home in writing a vert.x application?

In this blog post I will look at using gulp, a node.js build tool, to build a vert.x 2 module.

Platform Installation

Before proceeding, be sure to have both the vert.x and node.js platforms installed. Vert.x will provide the run-time for our application, and node.js will provide us with the build environment for our project. Refer to the vert.x install docs and the node and npm install docs for further details.

Project layout

The gulp.js build tool has us apply transformations to streams of our source code, and as such doesn’t dictate how we structure our source code within our project. The structure I chose is as follows:

.
    ├── gulpfile.js
    ├── node_modules
    │   └── ...
    ├── package.json
    ├── src
    │   ├── app.js
    │   ├── mod.json
    │   └── ...
    ├── tasks
    │   ├── vertx.gulp.js
    │   └── zip.gulp.js
    └── vertx_modules
        └── ...

The package.json file manages the npm dependencies for our gulp.js build, where those dependencies are stored in the node_modules folder. The gulpfile.js file is our gulp build file, and incorporates individual build tasks defined in the tasks folder. The src folder contains our the source for our vert.x module, and finally the vertx_modules folder contains the vert.x modules on which our application depends.

The gulp build

The gulp build file (gulpfile.js) is pretty straightforward; the top-level gulp file is used to configure the project, with individual tasks defined in separate files. These files are then included using the require statement.

gulpfile.js
process.env.VERTX_MODS = 'vertx_modules';
    
    var gulp = require('gulp');
    
    var opts = {
      module: {
        group: 'ca.bleathem',
        artifact: 'demo',
        version: '0.0.1'
      },
      paths: {
        src: 'src/**/*',
        dist: 'dist'
      }
    };
    
    opts.module.name = opts.module.group + '~'
                     + opts.module.artifact + '~'
                     + opts.module.version + '.zip';
    opts.paths.cp = 'src';
    
    require('./tasks/vertx.gulp.js')(gulp, opts);
    require('./tasks/zip.gulp.js')(gulp, opts);
    
    gulp.task('default', ['vertx']);

Notice the VERTX_MODS environment variable is set in the gulpfile. Using the build file to programtically set environment variable depending on the deployment target (production/development) can be a powerful technique. Here we set VERTX_MODS to store vertx modules in a folder paralleling the node.js modules.

The *.gulp.js build files containing the individual gulp task definitions are stored in the gulp sub folder.

...
    ├── tasks
    │   ├── vertx.gulp.js
    │   └── zip.gulp.js
    ...

Let’s explore these vertx and zip tasks further.

The vert.x gulp task

The gulp plugin guidelines recommend not creating a plugin for a task that can "be done easily with an existing node module". To this end, we’ll start by seeing how far we can by leveraging the abilities of node to spawn a child process. Below is a gulp task that runs the vert.x module that is our sample application:

vertx.gulp.js
var spawn = require('child_process').spawn
      , gutil = require('gulp-util');
    
    module.exports = function(gulp, opts) {
      gulp.task('vertx', [], function(done) {
        var child = spawn('vertx', ['runmod', opts.module.name, '-cp', opts.paths.cp ], {cwd: process.cwd()}),
            stdout = '',
            stderr = '';
    
        child.stdout.setEncoding('utf8');
        child.stdout.on('data', function (data) {
            stdout += data;
            gutil.log(data.slice(0, data.length - 1));
        });
    
        child.stderr.setEncoding('utf8');
        child.stderr.on('data', function (data) {
            stderr += data;
            gutil.log(gutil.colors.red(data.slice(0, data.length - 1)));
            gutil.beep();
        });
    
        child.on('close', function(code) {
            gutil.log('Done with exit code', code);
            done();
        });
      });
    };

The bulk of the above listing deals with re-directing and formatting the output of the vert.x child process. The invocation of the spawn function is the interesting part, and is where we pass our arguments to the vert.x process. In our case we want to run the module that is our sample project, and we set the vert.x classpath to our source folder to allow for on-the-fly code changes.

Invoking the build via the command gulp vertx will start vert.x, running the module in our project.

The zip gulp task

The distribution format for vert.x is a wonderfully simple zip format. This makes it easy to use a the gulp-zip plugin to zip up the file and create a bundle for our module.

vertx.gulp.js
var zip = require('gulp-zip');
    
    module.exports = function(gulp, opts) {
      return gulp.task('zip', function() {
        return gulp.src(opts.paths.src)
          .pipe(zip(opts.module.name))
          .pipe(gulp.dest(opts.paths.dist));
      });
    };

The above source transformation is a trivial one. Those familiar with gulp will recognize we could easily add additional stream transformations here, eg. compiling coffescript, minifying client code, compiling sass etc.

On to vert.x 3

The above build works well for vert.x 2. However vert.x 3 is around the corner and introduces many changes. The changes relevant to our gulp build include:

  1. Vert.x 3 will do away with modules and flatten the classpath across verticals. This will directly affect how we structure our source code and invoke vert.x from our gulpfile.

  2. Vert.x 3 will also resolve packaged verticles from npm, which will align nicely with our npm-based build approach.

Stay tuned for a new post addressing a gulp.js build targeting vert.x 3.


Tuesday, January 20, 2015

RichFaces 4.5.2.Final Release Announcement

RichFaces

RichFaces 4.5.2.Final is now available for download! Check out @Michal Petrov's blog for the detailed RichFaces 4.5.2.Final release announcement.


Tuesday, December 2, 2014

RichFaces 4.5.1.Final Release Announcement

RichFaces

RichFaces 4.5.1.Final is now available for download! Check out @Michal Petrov's blog for details of what this 4.5.1.Final release includes.


Wednesday, October 29, 2014

RichFaces 4.5.0.Final Release Announcement

RichFaces

RichFaces 4.5.0.Final is now available for download! RichFaces 4.5 is a significant improvement over the previous 4.3 release, offering JSF 2.2 compatibility, new components, a simplified build and distribution layout, and Page Fragments for simplified functional testing. Please read below for details on each of these improvements..

To try out this release: You can download the distribution directly, or for maven users, increment the RichFaces version in your pom.xml to 4.5.0.Final. For more information on setting up a RichFaces 4 application, refer to our getting started guide.

Compatibility with RichFaces 4.3: RichFaces 4.5 is intended to be backwards compatibility with RichFaces 4.3 and should be a drop in replacement into your applications, requiring only changes in your pom.xml.

Any breaking changes with RichFaces 4.5 are being tracked in our GitHub wiki migration page. Please update that wiki page with a Pull Request if you find any incompatibilities.

JSF 2.2 Compatibility

RichFaces 4.5 has been developed and tested against both JSF 2.1 and 2.2. Go forth and take advantage of the new features available in JSF 2.2.

Chart components

Thanks to the hard work of our Google Summer of Code student and subsequent intern Lukas Macko, we are providing a set of Chart components in RichFaces 4.5. Use these components to graphically represent the data in your applications with a similar API as the rest of your JSF components.

Read more about the RichFaces 4.5 charts in Michal Petrov’s blog post on using charts.

Component improvements

A number of existing components have seen some improvements in RichFaces 4.5. These are outlined below:

Select component with autocomplete

The <rich:select> component has been augmented to support the same auto-completing functionality as the <rich:autocomplete> component. The rule-of-thumb to keep in mind when deciding between incorporating either of these similar components is as follows:

  • use the <rich:select> component when auto-completing a list of backend objects.

  • use the <rich:autocomplete> component when auto-completing with text-based input.

Built-in sorting and filtering of the DataTable

The <rich:dataTable> has picked up the built-in sorting and filtering capabilities that have been available for some time in it’s big brother the <rich:extendedDataTable>.

If you are already using the <rich:dataTable> in your application with custom controls, and do not wish to take advantage of the built-in controls, then please refer to the Component reference for instructions on disabling the builtin sorting and filtering controls.

Push with web-sockets

We’ve upgraded our atmosphere dependency to version 2.2, allowing our <a4j:push> component to take advantage of web-sockets. The component will gracefully fall-back to long-polling when web-sockets are not available in either your deployment container nor in the browser.

Fileupload

The <rich:fileupload> component has been re-worked to take advantage of the new APIs provided with the Servlet 3.0 specification. This re-implementation has allowed us to add some new features. Check out the Fileupload sample in the showcase to play with the new implementation.

Under the hood

A number of improvements have been made in RichFaces 4.5 under the hood, these include:

A new ExtendedPartialViewContext

The new RichFaces EPVC extends the PVC in Mojarra, rather than fork it. This has the effect of not only making our EPVC easier to maintain with new Mojarra releases, but also eases compatibility with other JSF libraries.

However, due to a patched bug in Mojarra, our new EPVC will only work with newer Mojarra releases. As such we’ve implemented a check verifying that you are running in a container providing Mojarra ≥ 2.1.28 or ≥ 2.2.6. MyFaces is not affected by this bug.

Simplified build

The build in RichFaces 4.5 has been greatly simplified. We’ve consolidated the RichFaces source down to a single github repository. Along with improvements to the CDK, we have been able to drastically reduce our developer turnaround time when working with the framework.

It’s also expected that this simpler build structure will encourage more community contributions, so get those Pull Requests coming!

Page Fragments

If you do functional testing (or would like to) and haven’t yet looked at the Arquillian Graphene Page Fragments, then do yourself a favour and do so.

This is all the more relevant with our RichFaces 4.5.0.Final release as our RichFaces QE team has ported their set of page fragments for RichFaces components to the framework, providing you with a stable set of page fragments matching the shipped components. Write your tests to the stable page fragments API, and you won’t be caught by surprise with failing tests when the DOM implementation of a component changes in a future release.

Have a look at one of our Framework tests to see these page fragments in action.

Asciidoc

We’ve ported the RichFaces docs from the hard-to-work-with docbook xml to the writer’s paradise that is Asciidoc. This migration was motivated in large part by the Asciidoc improvements introduced by the Asciidoctor team. Thanks guys!

The docs are on github and ready for pull requests!

Release Notes

Check out the Release notes for a list of the issues addressed since the 4.5.0.CR2 release.

A bug with Mojarra

An unfortunate regression in Mojarra caused by the fix to JAVASERVERFACES-3152 has broken a number of RichFaces components when nested in a <ui:repeat> component (see RFPL-3506). We are working with the Mojarra team to see this resolved (via JAVASERVERFACES-3452).

In the mean time please use the <a4j:repeat> component as a workaround.

Next steps

We will follow on the 4.5.0.Final release with a series of micro releases further improving the stability of our framework. There are no planned additional releases of the 4.3 branch.


Thursday, October 16, 2014

RichFaces 4.5.0.CR2 Release Announcement

RichFaces

We have a second candidate release for RichFaces 4.5 (4.5.0.CR2) available. We’ve fixed a couple of regressions uncovered by both our community and QA team. Thanks guys! Read on for the specifics of what was fixed in this release.

To try out this release: You can download the distribution directly, or for maven users, increment the RichFaces version in your pom.xml to 4.5.0.CR2. For more information on setting up a RichFaces 4 application, refer to our getting started guide.

Compatibility with RichFaces 4.3: RichFaces 4.5 is intended to be backwards compatibility with RichFaces 4.3 and should be a drop in replacement into your applications, requiring only changes in your pom.xml.

Any breaking changes with RichFaces 4.5 are being tracked in our GitHub wiki migration page. Please update that wiki page with a Pull Request if you find any incompatibilities.

Bug

  • RF-13217 - ITFileUpload framework test freezes on PhantomJS

  • RF-13839 - Drop-down menu page fragment should have show event aligned with the component

  • RF-13845 - Showcase select sample - new autocomplete like sample has wrong color or typed text

  • RF-13851 - Selected item in rich:select is not highlighted.

  • RF-13852 - When rich:select is included in EDT, navigation with up/down keys in the select list is not possible.

  • RF-13854 - The width option of the style attribute in rich:select does not work

  • RF-13860 - Richfaces Photoalbum example - tree navigation doesn’t work after deployment into EAP-6.3.1 with JRE-1.6

  • RF-13862 - Headers are stationary in rich:extendedTable with tabbed rich:column movement

  • RF-13864 - The tab key does not render the value when entered manually in rich:select

  • RF-13865 - Revert the rename of a4jSkin to richSkin, changing it back to a4jSkin

  • RF-13869 - page-fragments: editor: switching to correct frame

  • RF-13872 - Ajax doesn’t accept array in execute/render anymore

  • RF-13874 - integration tests: tests with Category FailingOnPhantomJS are skipped on Chrome

  • RF-13875 - RF 4.5 : a4j:push component fails on reconnect in push-demo

  • RF-13876 - Command button/link, jsFunction and poll missing parameter bypassUpdates

Enhancement

  • RF-13301 - Favor use of Page Fragments in Framework Tests

  • RF-13853 - page-fragments: refactor implementation part of orderingList, pickList

  • RF-13870 - showcase tests: select correct war classifier for activated integration profile

Feature Request

  • RF-13859 - Selecting an item while typing in rich:select does not work when enableManualInput=false.

Next steps

We will again let this 4.5.0.CR2 release "bake" in the community for the next week, and determine from your feedback whether or not we need a 4.5.0.CR3 release. If no blockers are found, we will proceed with our 4.5.0.Final release. So please be sure to this release out in your applications and file any issues ASAP!


Wednesday, October 1, 2014

RichFaces 4.5.0.CR1 Release Announcement

RichFaces

We have a first candidate release for RichFaces 4.5 (4.5.0.CR1) available. With this candidate release we’ve further improved our stability over our beta releases, with a special focus on backwards compatibility with RichFaces 4.3. Read below for details of what is included in this release.

To try out this release: You can download the distribution directly, or for maven users, increment the RichFaces version in your pom.xml to 4.5.0.CR1. For more information on setting up a RichFaces 4 application, refer to our getting started guide.

Compatibility with RichFaces 4.3

RichFaces 4.5 is a significant release introducing many changes to the framework. However with all these changes maintaining backwards compatibility with RichFaces 4.3 has been a priority. As such, RichFaces 4.5 should be a drop in replacement into your applications, provided you make the necessary changes in your pom.xml.

Any breaking changes with RichFaces 4.5 are being tracked in our GitHub wiki migration page. Please update that wiki page with a Pull Request if you find any incompatibilities.

Bug

  • RF-8904 - Update project build to integrate jsDoc

  • RF-12312 - rich:select - duplicate labels

  • RF-13290 - Push framework tests fail after upgrade to 1.0.17 (probably Warp issue)

  • RF-13504 - Test that the ExtendedPartialViewContext writes the ClientWindow ID updates to the partial response

  • RF-13522 - Component reference - text for links to figures doesn’t contain "Figure" prefix

  • RF-13788 - ExtendedDataTable supports the undocumented attribute "render"

  • RF-13812 - rich:validator misunderstands EL expressions inside Bean Validation 1.1

  • RF-13816 - Include Page Fragments in the RichFaces distribution and javadoc

  • RF-13818 - JSF server vs application Please upgrade to at least Mojarra 2.1.28 or 2.2.6

  • RF-13821 - InputNumber* component class changes cause backward compatibility problems

  • RF-13822 - Mobile showcase: fileupload sample is not working [myfaces]

  • RF-13823 - showcase: contextMenu: missing picturesUtils.js resource [myfaces]

  • RF-13826 - Media output: onclick doesn’t work

  • RF-13827 - Selection mode simple and multiple in ExtendedDataTable throws JS error in Chrome 36

  • RF-13830 - Tooltip not attached must specify target=""

  • RF-13838 - ExtendedPartialViewContext.java is missing method setPartialRequest

  • RF-13840 - a4j:jsFunction - oncomplete is called twice

  • RF-13843 - rich:fileUpload should use feature detection for File API

  • RF-13846 - page-fragments: orderingList, pickList: rename method getContentAreaElements to getContentAreaElement

  • RF-13848 - page-fragments: orderingList: remove duplicated field

  • RF-13849 - page-fragments: pickList: stackoverflow in orderingList part

Component Upgrade

  • RF-13475 - NullPointException when using Richfaces with ehcache

  • RF-13841 - Upgrade Selenium to 2.43.1

Enhancement

  • RF-13414 - The showcase chart demo of event handling renders seemingly redundant info

  • RF-13831 - Review page fragments

  • RF-13832 - Built-in filtering and sorting inside richcollapsibleSubTable

  • RF-13833 - Doc for r:tree selectionChangeListener attribute is misplaced with toggleListener attribute doc

  • RF-13847 - page-fragments: pickList: rename methods for returning contentAreaElement

  • RF-13850 - page-fragments: refactor implementation part of collapsiblePanel, dataGrid, fileUpload, inplaceSelect, orderingList, pickList

Task

  • RF-13834 - Alias the javascript method RichFaces.component to RichFaces.$

  • RF-13835 - Revert package and class names changes in 4.5

  • RF-13837 - Add "chart" prefix to chart components

Next steps

We will let this 4.5.0.CR1 release "bake" in the community for the next week, and determine from your feedback whether or not we need a 4.5.0.CR2 release. If no blockers are found, we will re-spin this 4.5.0.CR1 release as our 4.5.0.Final release. So please be sure to this release out in your applications and file any issues ASAP!


Thursday, September 11, 2014

RichFaces 4.5.0.Beta2 Release Announcement

RichFaces

The second beta release of RichFaces 4.5 (4.5.0.Beta2) has been released. This release focuses on stabilizing RichFaces 4.5.0.Beta1 with a number of bug fixes. Read below for a summary of the issues resolved.

To try out this release: You can download the distribution directly, or for maven users, increment the RichFaces version in your pom.xml to 4.5.0.Beta2. For more information on setting up a RichFaces 4 application, refer to our getting started guide.

Bug

  • RF-11090 - rich:collapsibleSubTable cannot be nested

  • RF-11656 - Nested collapsibleSubTable always expanded

  • RF-12399 - Showcase: rich:contextmenu cannot find image

  • RF-13081 - Facets "disabled" not working for dataScroller

  • RF-13645 - contextMenu for extendedDataTable breaks after ajax render of contextMenu

  • RF-13655 - Popup Panel autosize does not work when its content is dynamically updated

  • RF-13708 - Photoalbum: refresh over index page throws error

  • RF-13722 - Document CDK Maven Changes for 4.5

  • RF-13747 - a4j:commandLink does not have a default event name

  • RF-13781 - Enable RichFaces to be built with the jdk6

  • RF-13783 - Placeholder: attribute styleClass doesn’t work inside inplace input and inplace select

  • RF-13787 - Push with EAP 6.3 not using WebSockets

  • RF-13790 - Showcase - dataTable Styling example - broken styling after built in sorting/filtering is enabled

  • RF-13791 - Push in Showcase with EAP 6.2

  • RF-13794 - FileUpload serverError on upload on Wildfly

  • RF-13795 - RichFaces build is broken when running integration with release profile

  • RF-13798 - Showcase: select sample is not working [myfaces]

  • RF-13803 - Push on Tomcat 8: Unable to load current conversations from the associated request

  • RF-13804 - rich:select selectFirst attribute not working

  • RF-13814 - Photoalbum cannot be deployed to EAP

  • RF-13817 - Both the Component Reference are missing the Revision History appendices

Component Upgrade

Enhancement

  • RF-12674 - Write framework tests for Autocomplete tokenizing feature

  • RF-13056 - Showcase - delete unused configuration for GAE

  • RF-13796 - Chart component - documentation improvement

Feature Request

  • RF-8701 - dataScroller: add facets support for customizations

  • RF-13797 - Integration tests - enable HTTPS testing on Wildfly

  • RF-13807 - Add a an autocomplete sample for the select component to the showcase

Task

  • RF-13765 - EDT: meta-components @footer, @header and @body are not documented

  • RF-13800 - docs: rich:select: add information about autocomplete functionality

Next steps

Work on RichFaces 4.5.0.CR1 is currently underway. Look for this first CR release to follow in the next week or two.