Skip navigation

After leading the JavaServer Faces implementation team through our 1.0 release I deciced to spend more time on developing the specification itself, and have handed the leadership over to the ever-so-capable Jayashri Visvanathan. Jayashri was a key contributor to the project during 1.0, and has lead the team through the 1.1 and subsequent releases. I'm devoting this blog to giving the community a chance to get to know Jayashri better, and to give her a chance to share her vision for the future of the JavaServer Faces project.

Ed Burns: How do you think the Java Enterprise community will benefit from having javaserverfaces as an open development project?

Jayashri Visvanathan: Thanks for the introduction as well as for your vote of confidence. Following are some of the important benefits of open development.

  • One of the major concerns of the community has been that they have no knowledge of what features/bugs would be addressed in the next release. With open development, they have access to issues list for the current release as well as for the future releases.

  • They get to file issues and track any updates to that issue. If they are subscribed to the alias, they can follow discussions about various issues including any code changes.

  • They are able to get access to the bug fixes/features on a day to day basis. Currently we don't have nightly builds set up but it will be available shortly.

  • They have access to latest source code. Once the JDL license for JSF is available, they will be able to modify and redistribute the binaries.

To summarize, they get to fully participate in the development of JSF, as an observer, code contributor or as a committer.

EB: What are your priorities for the project over the next 6 months?

JV: Here's an unprioritized short list of some things I'd like to do

  • Make nightly builds available.

  • Set up cruise control so that it can viewed externally. For those who are not aware, cruise control defines a build cycle determines if a build is necessary, if so builds, runs tests, creates a log file, and sends notifications. Right now, this is running on a Sun system and we would like to make it available to everyone.

  • Start accepting external contributions. To make this happen we are looking at how to make it as easy as possible for external committers to run the test suites.

  • Continue to focus on improving the performance of the RI in order to make it production quality.

  • Build a community of developers who are committed to increasing the quality of Sun's JavaServer Faces implementation.

EB: How do you feel about competing with other JavaServer Faces implementations? Where do you see your implementation excelling?

JV:JSF RI tracks the spec very closely serving as a proof of concept for the JSF specification. In addition, thanks to Ryan Lubke, our TCK Engineer, the tests are being run on a continous basis to catch any spec violations early and often. Our goal is to make the RI production quality and highly scalable.

EB: How do you plan to address feature requests and bug reports?

JV: Bugs will be evaluated within a week. If the bug is critical enough or is show stopper, we would make every effort to address it immediately. I would like to take this opportunity to encourage everyone to file issues for all bugs and any feature requests they have. To help us to quickly fix the bug, be sure to include as much information with your report as possible such as a test case, your platform, version numbers and steps to reproduce the problem.

EB: What can you tell us about your process for accepting contributors to the project?

JV: We are currently accepting code contributions/patches from the community. Detailed guidelines for submitting patches is in FAQ. In order for your patch to be accepted quickly, please attach a test case. JSF team follows test first development & code review process strictly, so if a patch doesn't have a test case, we would have to create/update an existing test for it which would delay the acceptance of your patch. Contributors who give frequent and valuable contributions can become a committer if they desire. Again,the FAQ details the JSF code development process.

EB: What do you see as some of the challenges this project may face?

JV: Our challenge would be make the RI highly scalable and of production quality in addition to keeping up with the latest spec revisions. With help from the community, its a definite possibility.

EB: How will you judge the success of the project?

JV: Based on community's feedback and their participation. JSF community has always been very vocal about pointing good and bad things about the specification as well as the RI and I hope they continue to do that and thats key to success of this project.

With that, I would like to thank you once again for introducing me and I look to forward to working with the Java Enterprise community.

The ourfaces project is intended to be a casual, yet very useful repository of JavaServer Faces components. I say casual because we want have a low barrier to entry for adding new components to the repository. The project leader, Matthias Unverzagt, has made it very easy to get started as a contributor, in four simple steps. Of course, if it's easy to be a contributor, it's even easier to be a user.

If you look at'll see there are at least ten different entries for JavaServer Faces component libraries, and most of them are not dollar cost free, nor are they free software. I feel it is important to have a high quality, open source, dollar cost free component library for Faces, and the OurFaces project intends to be just that.

Let's take a look at how the project is structured. We've made the project easy to access by building the component catalog in an easy-to-deploy WAR file during the standard build process. This enables you to explore the runtime performance of the components. The source tree is broken down as follows.



    Any licenses that apply to this project go here



      Where <component> is one of the components in the catalog.
      Currently, we have calendar, code, tree, and table.


          Any artifacts relating to displaying this component in the
          catalog.  These are user-level artifacts, not core component


              Java code for displaying the component in the catalog


               Any non-java code artifacts for displaying the component
               in the catalog.  This includes skinability, sample HTML,
               CSS, XML config files, etc.


          The XML file that declares the owner of this component.  The
          owner is responsible for everything in this component,
          including its display in the catalog.  


          The java code that makes up the UIComponent subclass,
          (optional) Renderer, and UIComponentTag subclass.


      Any supporting code relating to the display of the catalog


      Any supporting code used by the components.

This framework allows the component library to accept contributions from arbitrary parties, while allowing each party to own their components in the repository. As you can see, we currently only have three components, so we're eager to accept more contributors. We hope that becoming a member of the java-enterprise community will give us more visibility.

Please feel free to read and post on the discussion forum!

Filter Blog

By date: