Thursday, August 30, 2012

Incremental build with RichFaces CDK


To whom of us using RichFaces CDK and being unsatisfied with a build time, our day just came!

CDK got an incremental build feature, which caches information collected during a Library compilation and store it on a hard drive.

Once you trigger a build for a second time, the last modification time of all sources is compared to last modification time of cache file.

When CDK recognizes that any source has changed, it will re-compile it and the collected data will be applied on Library model again, effectively rewriting old data.

How to Configure Incremental Build

How to configure incremental build in your CDK project? It's pretty simple: you don't need to do anything.

Incremental build is turned on by default to make your life easier and to save your precious time.


I recommend you to configure the fast CDK turnaround using JRebel - together with the incremental build, nothing will beat you in the rich JSF components development time.

Troubleshooting

When using incremental build at current implementation, be aware that in some cases when you do structural changes (e.g. renaming methods), you may get to a point where the incrementally generated sources will not be valid - sometimes it won't make any trouble (attribute renaming), sometimes sources generated by CDK might not be even compilable at all.

In this case, you just need to recompile the sources from scratch, either with additional maven-cdk-plugin configuration

$ mvn cdk:generate -Dcdk.recompile=true


or using command line interface:

$ bash run.sh --force-recompile

However in most cases, incremental build will work just fine. :-)

Improvement

Using incremental build, I have achieved build-time improvement from 10 545 ms to 1 622 ms in Bootstrap sandbox project.

Such an improvement will allow us to re-factor RichFaces component suite to be developed just from one maven module and simplify a build a lot.

Enjoy JSF component development

Friday, August 3, 2012

JSF meets Skinning Awesomeness of LESS

A strength of JSF is in how it enables you to quickly write applications, providing you with a plethora of components abstracting complex functions.

Skinning, Styling & CSS



But when it comes to skinning and styling those components, JSF is not very helpful. But let’s not malign JSF here - it's not the fault of JSF.

Rather, we should blame CSS, which lacks the dynamicity that would allow the strong skinning features.


CSS Pre-Processors to the Rescue


That's exactly where technologies like LESS and SASS come in. They are processors which provide an  alternative syntax similar to CSS, that basically allow you to do magic with your style-sheets and how they are are structured - variables, mixins, functions, etc.

As the RichFaces team is currently working on leveraging Twitter Bootstrap, we want to embrace its beauties completely, and thus adopted its ability to style components in a simple and reusable way, while also enabling style extensions.

Now, you can see this magic in the RichFaces Bootstrap showcase.

What is this magic and how you can achieve it? Let's see in this demo:



Incredibly fast styling with JSF and LESS from Lukas Fryc on Vimeo.


You can clone the Bootstrap showcase on GitHub repository:

https://github.com/richfaces/sandbox

How does it work?

When the project is imported to the IDE, you can achieve instant turnaround without need to reload (or even re-deploy) anything - you just turn on the Instant LESS functionality using a bookmark with the following URL and the client-side LESS compiler will take care of the rest:

javascript:less.instant.toggle();


Your browser will now constantly watch for changes in the application resources.

We use JRebel to ensure resources are pushed to the server immediately after we save them in the IDE. This isn't necessary if you use an expanded WAR, but we load LESS resources from JAR projects and that's where servers usually fall short. Luckily JRebel comes to save our butt, making possible the hot-reloading of resources within a JAR that are served using the JSF Resource Handler.

Production Mode

The above method works well while in the Development stage of a project. But with that approach, LESS compiles resources in the browser and thus would slow down your application.

In Production project stage is where built-time compilation comes into play. We use the popular project wro4j - a pre-processor, minifier and optimizer for many alternative syntaxes for web languages.  Specifically we are using the wro4j-maven-plugin and M2E connector for this Maven plugin (written by our fellow Fred Bricon, who wrote a blog about usage of this plugin).

Let's check the Production Mode out, it is also as awesome as the Development Mode and its instant turnaround feature!