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

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!

In the foothills of Alps - wrap-up of ConFess 2012

Last week, I have been in Austria at ConFess conference.

From my perspective, the conference underwent two significant changes: the venue was moved to Leogang, Austria and at second I was speaking there. :-)

For the first point, I really loved the place - I'm the big fan of hiking and alpinism, so I really enjoyed the moments when we were discussing outside the conference rooms, breathing the fresh air and admiring the beauties of surrounding nature.

At second it was really pleasure to speak at ConFess, as it is the first conference where I've ever been, and I like returning there.

My first talk was about latest movements in world of HTML5, what developers needs to consider and how JSF and RichFaces fit that story.

Second talk was structured as comprehensive guide to designing test suites for Java EE applications. I have revealed some of latest movements at planet Arquillian (like JSFUnit.NG or JRebel extension).

Thanks to Jan Papousek who captured the photo.

Graphene 1.0.0.Final Released

The Arquillian Graphene, the project focusing on making a real-browser automation a breeze, is now reaching first Final release.

The Graphene is joining rest of the Arquillian party, building on top of Arquillian framework integration and Drone extension, which reached their stable version yesterday.

The Mission

The project was started to address simplification of covering AJAX-enabled applications with browser automation tests.

While Selenium project is focusing on unified API, integration with variety of browsers, Graphene project is addressing the real-world testing challenges:

• rapid development
• straight-forward
• readable API
• fast turnaround
• object-oriented
• type-safe API
• dependency injection of thread-local context
• instabilities and speed of execution in continuous integration
• jQuery selectors
• request guards

Availability

The Graphene bits are available in JBoss Maven repository, dual-licensed under LGPL v2.1 (backward-compatibility) and ASL v2.0 (which uses rest of the Arquillian sub-projects).

For those who are already using the framework with Maven, you can simply increase the version to 1.0.0.Final.

You can start with the tests using our Getting StartJBoss Maven repositoryed guide.

The Future

Right now we are heavily working on making the new version of Graphene 2 on the road.

Selenium 2 with its WebDriver API made huge progress with API accessibility and readability - it's already pleasure to work with this API in Java world.

However still there are many lacks we are going to address with Graphene 2, building on top of concepts brought in Graphene 1 and adding new features, which opens world of new possibilities:

• dependency injection of thread-local context
• fast development turnaround
• cross-cutting concerns (command interception)
• request guards
• page extensions
• component objects
• extension of page objects concept
• JavaScript test execution from within Selenium test

If you enjoy testing and you are unsatisfied with the current browser automation tooling, it's perfect time to step in and help us to bring the future!

The Project Info

Source code: https://github.com/arquillian/arquillian-graphene

Documentation: https://docs.jboss.org/author/display/ARQGRA/Home

Issue tracker: https://issues.jboss.org/browse/ARQGRA

Full-Fledged Debugging for Mobile Browsers

A debugging of desktop applications is very common task in the world of web development. We might say the tooling here is highly developed and you can find everything you require and pretty easily. You can just use all those Firebugs, Chrome Web Inspectors, IE Developers Tools, etc.

Not so in world of mobile devices!

Hard Time Debugging Web Apps on Mobiles

The debugging applications on mobile were always problem - the mobile safari for iPhone/iPad offers you at least error console, so you might know when something is going wrong. The Android built-in browser does not even provide you such tool!

WebKit Web Inspector

But the WebKit based browsers has solution to this - they offers WebKit Web Inspector, which you might be familiar with from using Chrome/Safari.

Fortunately, WebKit functionality has arrived to mobile browsers yet!

Inspector for Safari / iPhone

From little bit of search, I have found Safari was enabled to use remote debugging bridge year ago!

Inspector for Chrome Beta / Android

But as Ubuntu/Android user, I wasn't able to use such a comfort. Until now!

I have upgraded my HTC to Android 4 yesterday and the Chrome Beta was the first application I installed there (it isn't available for previous Android releases).

Today I have dived into RichFaces issue which occurred on mobiles. What a pain it could be when trying to find the cause, since mobile browsers doesn't even provide you the exact line where JavaScript error has occurred.

And guess what? Chrome Beta already allows the same like Safari - WebKit Web Inspector through the USB debugging bridge.

How To...

The process is quite straight-forward:

• setup the USB debugging
• let's start from step 2 - Turn on "USB Debugging" on your device.
• for Ubuntu users, one additional step is required which involves registration device into udev system (described in the link above)
• enable USB web debugging in Chrome Beta 
• involving installation of Android SDK

Incredibly Fast JSF Component Development

Why is a JSF components development so painful?

It would be really great if I could develop full-blown JSF components wrapping some JavaScript UI widget as fast as I'm developing plain HTML, wouldn't it?

Just two words: fast turnaround!

Every tool and every framework which tries to simplify a process should have a strategy to allow a fast turnaround. It is lowering a learning curve and saves developers many invaluable hours. And mainly it makes working with the a tool a pleasure!

RichFaces CDK

The CDK project is sample of such a powerful tool - it allows you to write just two pieces -

• a Java component interface,
• a HTML renderer (with Facelets-like syntax),

and then it takes these definitions and

• generates all the boilerplate code automatically including
• all the Java code,
• configurations (faces-config.xml and *.taglib.xml),
• and a VDL documentation.

Brian Leathem has written series of articles introducing how easy can JSF component development be when using RichFaces CDK.

But besides it is the powerful tool, you can also achieve a really fast development turnaround using CDK- just by using proper tools!

Quick Turnaround with RichFaces CDK

There is guide which covers how to setup your tooling to start with a development.

It covers setting up the component and demo project in JBoss Tools (on top of Eclipse IDE) and how to automatically trigger build when you change CDK resources.

And to make the deployment phase as quick as possible?

We are using JRebel to hot-deploy built resources into JBoss AS 7, which is itself f&@#ng fast.

That's it!

You can just save & refresh the page!

The pictures used in the blog are only illustrative, taken by various authors and published under Creative Commons license. The references: the toolkit by Ryan Hyde and the trains by Joel Down

Graphene CR3 Released & How To Migrate from Ajocado?

The project Ajocado has been renamed to Graphene.

The first release under the new name waits for you in Maven repositories.

Migration Path

Fortunately, the migration to new name in your project is very smooth, you can even continue to use original APIs.

Java Classes

The packages of the Java classes have not been renamed, the only change is addition of three new interfaces/utilities and deprecation of the old ones:

Ajocado -> Graphene

AjaxSelenium -> GrapheneSelenium
AjocadoConfiguration -> GrapheneConfiguration

AjocadoContext -> GrapheneSeleniumContextM

AjocadoConfigurationContext -> GrapheneConfigurationContext

The original names has been deprecated, but it doesn't prevent to use current tests as they are - the deprecated classes will continue to be part of the project.

Configuration

The simple change in the arquillian.xml descriptor is needed, you just need to change ajocado to graphene:

<extension qualifier="graphene">
    ...
</extension>

Maven Artifacts

The most significant change underwent dependency system, so let me talk a more little bit about that:

In Ajocado CR2, there was only one dependency necessary to import all the JUnit/TestNG and all Arquillian dependencies.

In Graphene CR3, you need to manage several dependencies - however it makes your usage of dependencies little more cleaner, since you know exactly what dependencies are imported.

At first, you need to import JUnit/TestNG dependency:

Test Framework

<!-- JUnit -->
<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.8.2</version>
    <scope>test</scope>
</dependency>

<!-- TestNG -->
<dependency>
    <groupId>org.testng</groupId>
    <artifactId>testng</artifactId>
    <version>5.14.6</version>
    <scope>test</scope>
</dependency>

Additionally, you need to choose between using Graphene as standalone or use Arquillian integration with containers:

Standalone Usage

In this mode, you don't use integration with containers, you need to manage the container and deployment at own:

<!-- Arquillian JUnit Standalone -->
<dependency>
    <groupId>org.jboss.arquillian.junit</groupId>
    <artifactId>arquillian-junit-standalone</artifactId>
    <version>1.0.0.CR7</version>
    <scope>test</scope>
</dependency>

or

<!-- Arquillian TestNG Standalone -->
<dependency>
    <groupId>org.jboss.arquillian.testng</groupId>
    <artifactId>arquillian-testng-standalone</artifactId>
    <version>1.0.0.CR7</version>
    <scope>test</scope>
</dependency>

Container usage

In the container mode, you need to provide deployable archive  (@Deployment) and the whole lifecycle of the container and deployment will be managed by Arquillian:

<!-- Arquillian JUnit Container -->
<dependency>
    <groupId>org.jboss.arquillian.junit</groupId>
    <artifactId>arquillian-junit-container</artifactId>
    <version>1.0.0.CR7</version>
    <scope>test</scope>
</dependency>

or

<!-- Arquillian TestNG Container -->
<dependency>
    <groupId>org.jboss.arquillian.testng</groupId>
    <artifactId>arquillian-testng-container</artifactId>
    <version>1.0.0.CR7</version>
    <scope>test</scope>
</dependency>

Graphene Dependency Chain

And finally it's necessary to import Arquillian Graphene dependency chain, which includes all other necessary dependencies (Graphene, Drone, Selenium):

<!-- Graphene dependency chain -->
<dependency>
    <groupId>org.jboss.arquillian.graphene</groupId>
    <artifactId>arquillian-graphene</artifactId>
    <version>1.0.0.CR3</version>
    <type>pom</type>
    <scope>test</scope>
</dependency>

What's next?

We are preparing to release Final later soon, the same as other dependencies in Arquillian ecosystem.

Thanks all the people who helped to test migration (Jan Papousek, Karel Piwko), so it is now pretty smooth.


More project information

Home page
Documentation
Issue tracker