Friday, June 14, 2013
I am excited to announce the release of RichFaces 5.0.0.Alpha1. While RichFaces 5.0.0.Alpha1 is an incredibly significant release (with almost all aspects of the framework seeing some changes) the release is in fact functionally equivalent to RichFaces 4.3.2.Final. So go ahead an try it out, and give us your feedback!
To try out this release: You can download the distribution directly, or for maven users, increment the RichFaces version in your pom.xml to 5.0.0.Alpha1. For more information on setting up a RichFaces 5 application, refer to our getting started guide.
Release highlights
The primary goals for RichFaces 5.0.0.Alpha1 were as follows:
Read a summary of each of these changes below, with links to blogs containing additional details.
Re-structure the build
The original design goal of the RichFaces 4 build was to enable partial builds of the framework to reduce the developer turnaround time in developing new components. While this breaking apart of the build into pieces was an attractive idea on paper, it didn’t work out that well in practice. The cost of assembling the partial build artifacts into the distributed framework was too high, and the various partial builds turned out to be more inter-dependent than expected.
With the 4.3.0.Final release of the RichFaces CDK we introduced an incremental build feature that removed the need for these partial builds. With this incremental build we could now build the framework in a piecewise manner, without requiring the framework to be segmented into partial builds. This led us to re-engineer the build based on current requirements and use cases, and was one of the primary motivating factors for RichFaces 5.
The end result is a build structure now contained within a single repository that is easier for both newcomers and seasoned RichFaces developers to grok. We hope this will encourage more community members to dive into the source code and contribute to the success of the framework. Should you still need to work with the RichFaces 4 source, it is available in the separate RichFaces 4 GitHub "organization"
Collapse the rich: and a4j: namespaces
As you may know, the current RichFaces framework is built from the old Ajax4Jsf project, and the original RichFaces component set. This distinction of the libraries has been preserved in the RichFaces framework with the use of the rich: and a4j: namespaces. However this distinction has blurred over time, and has unfortunately become a barrier to adoption for new RichFaces users.
In RichFaces 5, starting with this Alpha1 release, we are collapsing the namespaces into the single r: namespace. This will ease adoption for new developers, and allow for a more intuitive tooling experience within your IDE.
Framework distribution simplification
Incorporating RichFaces into your applications is easier with RichFaces 5. We now distribute a single richfaces.jar. No more separate API/UI/Impl jars, and no more BOM! If you are using maven, simply add the RichFaces jar to your project as in:
<dependency>
<groupId>org.richfaces</groupId>
<artifactId>richfaces</artifactId>
<version>5.0.0.Alpha1</version>
</dependency>
Improvements to testing
Testing has always been a primary concern of the RichFaces project. In RichFaces 5 we have taken our testing efforts to the next level with the incorporation of the Arquillian Graphene and Arquillian Warp extensions.
Move to asciidoc for our documentation
Last but not least I’ll mention the improvements we’ve made to our documentation workflow. Docs for RichFaces have always been a big part of the project. However we recently started to notice we had a large barrier for doc contributions that were anything more substantial than minor edits and small additions. This was due to the manual/direct editing of the Docbook XML source. XML is simply not conducive to an efficient authorship workflow.
In RichFaces 5.0.0.Alpha1 we have incorporated AsciiDoc into the top of our existing Docbook tool-chain. This has dramatically improved our documentation contribution workflow without compromising any flexibility nor expressibility. The RichFaces 5 docs are already quite more accessible than the RichFaces 4 ones, and we’ve only just begun to re-vamp the content.
Monday, June 10, 2013
With RichFaces 5 we have made a significant change to our documentation tool-chain with the introduction of AsciiDoc to simplify the task of authoring and editing the RichFaces documentation. Our documentation has for a long time been based on Docbook xml against which we have applied the Red Hat PressGang XSLT to create the HTML and PDF output of our docs.
Additionally the Docbook xml is fed downstream into Red Hat’s Web Framework Kit product (WFK), where it undergoes further transformations to fit well into Red Hat’s product documentation. Docbook xml is great for such manipulations, but it is by no means straight-forward to author. Anything more than simple edits quickly turns into a complex task.
Bring in the AsciiDoc!
Fortunately we have been able to remedy this problem, without sacrificing any of the power and flexibility of our Docbook tool-chain, by converting all our Docbook source into AsciiDoc. The AsciiDoc source is in turn converted back into Docbook xml, and fed into our existing tool-chain. This toolchain is a set of Pressgang XSLT files that takes the Docbook xml and converts it into our published PDF and HTML docs.
The capabilities of AsciiDoc are well demonstrated by the fact that we were able to create identical HTML and PDF docs using the AsciiDoc generated Docbook xml, without making any changes to our Docbook tool-chain. AsciiDoc is indeed a highly expressive markup language. On the other hand, AsciiDoc is only as complex as you want it to be - in basic use cases it’s as simple to read as Markdown.
The one-time conversion to AsciiDoc
Converting the Docbook xml into AsciiDoc however was not a simple task. We had a significant step forward by starting with the docbook2asciidoc XSLT project from O’Reilly media that converts Docbook xml into AsciiDoc. Jason Porter had already forked the project, introducing some changes to handle Red Hat flavoured Docbook.
We forked that fork, and introduced a number of additional changes to the XSLT to properly convert the Docbook xml into AsciiDoc. This conversion took us 98% of the way there, the final leg of the conversion was finished with some regexps and manual fine-tuning.
We also looked at the Pandoc project - a multi-purpose document converter that is able to output Docbook xml. We stuck with the XSLT for two reasons:
-
Out-of-the-box the XSLT brought us closer to our target.
-
Our XSLT expertise allowed us to hack the docbook2asciidoc to suit our needs, wheres Pandoc is written in Haskell which presented too a steep learning curve for a one off migration.
Although had our initial format not been xml, Pandoc would probably have been a better choice. Hopefully the Asciidoctor project is able to fill this conversion-to-asciidoc void in a future release.
Checkout the results, here are links to the AsciiDoc files on GitHub. Notice how GitHub renders the files, you can click the "raw" buttons to see the AsciiDoc source.
Asciidoctor
A word on AsciiDoc implementations. AsciiDoc is by no means a new kid on the block - the original python implementation has been around since 2002. However in 2012 a second implementation of AsciiDoc was begun called Asciidoctor. Written in Ruby, Asciidoctor has recently caught up with the original AsciiDoc implementation, and in many ways surpassed it. Asciidoctor is amazingly fast, rendering documents an order of magnitude more quickly than the original python implementation.
Coupled with these general improvements, the Asciidoctor community has done a great job integrating the ruby-based Asciidoctor with java via the asciidoctor-java-integration project. This java integration is then used to create a full-featured asciidoctor-maven-plugin, making Asciidoctor a natural choice and a good fit into our existing tool-chain.
Changes with RichFaces 5
Following the AsciiDoc conversion, we put the new format to the test with a massive edit of the docs to reflect the changes we introduced to the framework in RichFaces 5. I’m happy to report that the transformation was a success - the doc changes were nearly trivial to implement. This is indeed a huge step forward for the project, and will enable us to provide you, our user community, with much better documentation.
Conversely, we are hoping the more accessible format will enable more of you to jump in and fix errors and provide additions as you notice gaps in the documentation. So jump in! Give the new docs a read, and click that edit button in GitHub to initiate a pull request with any improvements you can suggest!
Next steps
While we will release RichFaces 5.0.0.Alpha1 with our new AsciiDoc based documentation, we are by no means down with our doc changes. Now that we have the new simpler AsciiDoc source in place, we will re-arrange the docs to provide something that is both more accessible and useful.
Friday, June 7, 2013
This week I attended the JAXConf 2013 conference for a third year in a row. This year JAXConf was held in Santa Clara, the heart of silicon valley. The conference once again had a fantastic line up of speakers, with well recognized industry leaders speaking on a variety of current and exciting topics. Unfortunately, JAX continued this year to be one of the best kept secrets of the tech industry on the West coast, with attendance not being as strong as many would have liked.
I attended a number of useful sessions covering topics from: testing web applications, the latest javascript frameworks, and what’s new in Java EE 7. There was one particularly interesting session in which it was "Tim Berglund vs. the audience" with his seemingly radical ideas on the current state of agile development - very entertaining (and informative!)
My own session went well. I took a opportunity to talk in stealth mode about the work we are doing in RichFaces 5 during my session on "poly-framework" web applications with Java EE. While I possibly spent too much time talking about Bootstrap, I think I got the point across about the power of Less CSS and CDI, with lots of plugs for the Errai and Aerogear projects. The session was recorded, I’ll update this post with a link to the video once it’s available.
It was great to attend another Java Posse live podcast recording. It made me realize that it’s been a couple of years since I last listened to the Java Posse podcast - ever since I stopped commuting. I enjoyed listening to their conversation quite a bit, particularly "@Carl Quinn’s" discussion of home automation with the Arduino chips in the "hobby projects" portion of the podcast - definitely something I’d like to make some time to fiddle around with.
I had a fun time visiting with David Blevins (of Tom EE fame) and his wife Amelia. As always the JAX crew themselves were great to hang out with - such gracious event hosts they are!
I look forward to the opportunity to speak again at JAXConf next year. I hope they can find the right location to maximize attendance, and keep this conference going for many years!
Thursday, May 16, 2013
I am excited to announce the release of RichFaces 4.3.2.Final. This 2nd minor release of the RichFaces 4.3 release series provides a number of bug fixes further increasing the stability of the framework.
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.3.2.Final. For more information on setting up a RichFaces 4 application, refer to our
getting started guide.
Release Highlights
This release of the RichFaces framework is not accompanied by a release of the CDK. The 4.3.2.Final release of RichFaces was created with the 4.3.1.Final version of the RichFaces CDK. Future RichFaces 4 releases will only be accompanied by a RichFaces CDK release when a CDK fix was required to enable the framework release.
With fixes to the extendedDataTable, tab panel, autocomplete, fileuplaod and popup panel, as well as some fixes addressing compatibility with the latest Mojarra release, you’ll definitely want to move your applications to this release and take advantage of these improvements. Refer to the release notes below for a complete listing of what has been fixed in this release.
Release Notes
Bug
- [RF-12193] – rich:extendedDataTable is blank on show
- [RF-12765] – Rich:tabPanel not possible to switch tabs when only dynamic tabs are present
- [RF-12812] – Autocomplete does not hide popup on tabbing to the next field
- [RF-12827] – Showcase – switching among dynamically created panels, tabs cease to function
- [RF-12839] – Toggle panels: ajax-related attributes do not work
- [RF-12846] – a4j:commandLink accesskey attribute missing
- [RF-12847] – Fix quickstart license and white space issues exposed by qstool report
- [RF-12848] – Error "source is not defined" after richfaces-jsf-event.js merge
- [RF-12850] – Popup panel: button's label is invisible in IE10
- [RF-12851] – The RichFaces kitchensink-rf quickstart/archetype incorrectly depend on the AS google guava module
- [RF-12858] – rich:calendar dateselect event is fired twice
- [RF-12868] – Update the Summary of the RichFaces kitchensink quickstart
- [RF-12893] – Partial response not ended correctly on exception
- [RF-12928] – ExtendedDataTable: columnsOrder doesnt work after changing order
- [RF-12931] – rich:fileupload broken with jsf.js changes in Mojarra 2.1.21
- [RF-12933] – rich:tooltip replace 'defaultContent' facet in docs and examples with 'loading'
- [RF-12958] – Popup panel opened from inside popup panel doesn't work
- [RF-12969] – rich:tabPanel: Click on already selected rich:tab causes JavaScript error
- [RF-12975] – rich:extendedDataTable – can not change order of columns
Component Upgrade
- [RF-12688] – Upgrade Guava from 11.02 to 13.0.1
- [RF-12780] – Upgrade to Mojarra 2.1.19
- [RF-12898] – Tie RichFaces 4.3 to CDK 4.3.1.Final
Enhancement
- [RF-12784] – Showcase readme – update deployment from eclipse part
- [RF-12786] – Showcase – rewrite readme to markdown
- [RF-12964] – Create appropriate push timeouts for the showcase
Feature Request
- [RF-12810] – Introduce profiles for verification of fundamental tests on Tomcat 6 and 7, TomEE 1.5 and GlassFish 3.1
- [RF-12849] – Showcase – update readme – remove obsolete, add new
- [RF-12935] – Fix resolution of framework tests' artifacts with version enforced
- [RF-12937] – Introduce a profile for running framework tests against JBoss EAP
- [RF-12938] – Update Shrinkwrap
- [RF-12940] – Showcase: fix path to outputPanel – compositeMessages sample source
- [RF-12941] – Showcase: ProgressBar demo – remove obsolete attribute and make the progress smoother
Task
- [RF-12843] – Apply unix style line-endings to the entire codebase
Moving forward
We’ve finished development of RichFaces 5.0.0.Alpha1, and our QA team is currently working on stabilizing for a release. So stay tuned for an exciting announcement of the availability of our first RichFaces 5 Alpha!
Wednesday, May 1, 2013
We’ve taken a break from our RichFaces 5 development to deliver a micro release of RichFaces 4.3. Today we are announcing that the first candidate release of this micro release is now available: RichFaces 4.3.2.CR1.
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.3.2.CR1. For more information on setting up a RichFaces 4 application, refer to our
getting started guide.
Release Notes
The issues addressed in this CR release are detailed in the 4.3.2 Release notes. The issues address bug fixes, library upgrades, and improvements to our testing infrastructure.
Please take the release for a spin, and let us know how it works for your application. Our extensive QA test suite is currently underway, we’ll release the final release shortly provided no blocking issues are uncovered.
Onwards
With this 4.3 micro release nearly complete, we’ll be shifting focus back to RichFaces 5. We hope to get the first Alpha release of RichFaces 5 out within a week or so – so stay tuned!
Thursday, March 7, 2013
The final release of RichFaces 4.3.1 (4.3.1.Final) has been released. This micro release addresses some bugs present in the 4.3.0.Final release, and offers some improvements on the new features introduced in that same release. Have a look at the 4.3.1.Final Release Notes for a complete listing if what was 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.3.1.Final. For more information on setting up a RichFaces 4 application, refer to our
getting started guide.
Release Highlights
Perhaps the most significant change introduced in this release is in issue RF-12803, where we’ve included the <a4j:ajax> JavaScript service extension in <f:ajax> execution. This service allows RichFaces components to serve and execute JavaScript after the page content is loaded, leading to improved page performance. As we’ve continued to use this service more extensively throughout our components, we realized we had to integrate the extension with the JSF 2 <f:ajax> behaviour, or we would forever be reminding people to use <a4j:ajax> instead (which you should be using anyway for all sorts of additional reasons).
The RichFaces push component has been upgraded to use the latest release of the Atmosphere library, with the resolution of RF-12689. If you haven’t yet started using the easy-to-use RichFaces push component in your application (with optional CDI and JMS integration) be sure to follow these 4 simple steps for RichFaces Push.
Moving forward
With RichFaces 4.3.1 out, we will next shift gears back into RichFaces 5 development, working on the new consolidated RichFaces 5 repository. Stay tuned for a first RichFaces 5 milestone release!
Tuesday, March 5, 2013
I will be returning to speak at JAXConf again this year. I’ll be speaking on the topic of Poly-framework Web applications with Java EE. The session will further explore the ideas I presented in my Polyglot Widgets blog, where I demoed a sample application written using three different web frameworks, demonstrating both a consistent look & feel, and uniform server-side programming model.
This topic will be particularly useful for those JAX attendees that have existing applications in production, yet like what they see with new web technologies and frameworks that they will learn about while attending JAXConf. Attendees may be curious how they can take advantage of the latest and greatest without re-writing already working software.
My JAXConf session will explore both client-side and server side techniques to allow disparate web frameworks to used side by side in a single application while providing users a consistent look & feel. We’ll look at sharing state between web frameworks, responding to server-side events with asynchronous http communication, and framework interop within a single page.
So if you are in the area from June 3-5 (or even if you are not!), come and check out my session at JAXConf. JAXConf has put together yet another roster of fantastic speakers and an excellent selection of topics. I look forward to attending many of the sessions myself, and am sure I will learn a lot!
