I describe the hudson jobs for Mojarra and the automated tests run by those jobs.
Here's a look at a draft of the JSF 2.2 JSR we plan to file with JCP.
Mojarra 2.1.0-b11 will likely be the final release of 2.1.0.
Ed announces release candidate 1 of Mojarra 2.1.0.
The Mojarra JSF Developer community can now know when it is safe to check in to the Mojarra source code repository.
In order to bring the testing matrix for Mojarra more in line with Oracle’s current engineering investment, we are planning to have all future Mojarra builds that are targeting the upcoming JSF 2.1 specification only support JavaSE 6 and beyond. Any 2.0.X and 1.2 builds will still continue to be built with Java SE 5.
I ask for people to share their thoughts on what wastes time during development with JSF.
This quick entry announces that we've started work on JSF 2.1 in earnest.
At the very beginning of my full time programmer career, when I worked at Silicon Graphics, Larry Wall and Randal Schwartz gave a brown bag session about their now legendary camel book. Naturally, I had them sign my copy, the front page of which I proudly display at left. Notice the “There’s More Than One Way To Do It!” stamp at the top. For better or worse, Perl is famous for this property. Less famous (or perhaps even infamous) for having more than one way to do it is JSF.
At the JSFdays conference last week, I was having lunch with a friend who is an experienced developer and the topic turned to JSF deployments in large projects. He mentioned that his project was bitten by the fact that there was more than one way to do it in JSF. If you give developers more than one way to do something, they'll take advantage of that capability. But, in a large project with many developers, this can lead to confusion and unmaintainability.
The simplest remedy is to establish firm and strong conventions for how to do things for which there is more than way one to do it. Of course, this is easier said than done, but I believe, as do Wall and Schwartz, that having more than one way to do it is generally an asset rather than a liability.
Ed shares his thoughts on a blog entry that is very critical of JSF.
I provide an annotated extract of Sebastian Hennebrueder's JS2 Evaluation and Test blog entry.
How to do Facelet custom tag handlers in JSF2.
I relate a quick story about a Mojarra code review that was gratifying.
I describe new subscription/unsubscription processes for email@example.com.
I assert that projects that have agressive schedules with clearly defined priorities combined with a lean team to meet that schedule will tend to generate software ghettos.
Ed is trying a new time management scheme: The Pomodoro Technique.
In this short entry, I'd like to bring to your attention a nifty CMS engine built on top of JavaEE: flexive.
JSR-276 is targeted at IDE vendors and the JSF component library vendors who depend on them for exposing their components to developers. The idea of JSR-276 is to let JSF component library vendors provide a far richer set of descriptive data about their components so that JSR-276 compliant tools can expose that data to the use
Ed responds to Byrne and Sulaycki of SpiderLabs about their upcoming BlackHat presentation about view state security in JSF.
An idea for a project: a JSF memcached range component.