the javaserver faces tools subproject
WTP LogoWTP Home
Meeting Notes: 2005-12-05.
  • Demo Milestone 1 Features
  • Questions and Answers
Meeting Notes


  • Raghu Srinivasan[RS]
  • Ian Trimble[IT]
  • Gerry Kessler[GK]
  • Justin Chen[JU]
  • Marshall Culpepper[JC]
  • Eric Norman
  • Sergei Pogrebny
  • Bob Gallagher[BG]
  • Jeffrey Liu[JL]
  • John Rohrlich
  • George DiCandio
  • David Williams
  • Nitin Dahyabhai
  • Lawrence Mandel


Introduction from Raghu Srinivasan

The two main objectives of the Milestone 1 release are the following:

  • Build the basic infrastructure required to develop a simple JSF application
  • Follow the Eclipse development processes and set up the necessary support to help in contributing to Eclipse.

Sybase is going to contribute the editor and a model for the Application configuration file and hence we have deferred any development on this area.
Gerry Kessler and Ian Trimble are the key contributors on this project.

Demo by Gerry Kessler

In Milestone 1, we have focused on building features that would make it easy for an end user to create a JSF JSP Web application. This includes the following functions:

  • Add required jars to the projects classpath.
  • Configure ‘web.xml’ with the JavaServer Faces Sevlet and define the servlet mapping.
  • Create a stub application configuration file (faces-config.xml)
  • Run a JSF JSP page on the target server.
Features demonstrated
  • JSF Project Intall and Uninstall Facets
  • JSF Library Registry
  • Run JSF JSP file on server
  • Extension plugin to add a library to the JSF Library Registry.

Questions and Answers

1) What are the issues in defining a class path container for each of the library in the registry?
Gerry: In our original design we had hoped to be able to allow the end-user to choose whether or not the library’s jars were copied to the project’s WEB-INF/lib folder or simply added to the classpath. We like the concept in general of the user choosing to deploy jars or not, as we cannot necessarily know what is target servlet container’s classpath. If the user decided not to deploy, the library jars would be placed in a classpath container for build purposes only.
Unfortunately our hands are currently tied with classpath container. The only way to be sure that jars are available to the server at runtime is to place them in the WEB-INF/lib directory. This is because with the loss of the “.deployable” folder post M7, there is no staging area to copy to even if there were a builder hook we could use for the copying.
Long term, it would be nice to support the idea of the user choosing to deploy sets of jars to a server or not. We will need to have discussions with the wtp server team regarding how best to support this.


2) Can a JSF Facet be added to an existing non-JSF Project?
Gerry: Yes, through the Project Facets section of the Properties page for the Web project.


3) What are the proper actions that should be taken when the JSF Project Facet is removed from a project?
Gerry: Apart from cleaning up the references in the ‘web.xml’ file, we would like to remove the JAR files that were ‘added’ to the project. Implementing as a class path container makes this uninstall easy. We intend to leave all other web artifacts alone (JSF JSP pages, application configuration files, etc.).


4) What is the difference between the class path container that you would like to implement and the Web Application Library?
Gerry: The Web Application Library container simply collects all the jars it finds in the WEB-INF/lib directory so that they are added to the classpath. We would like to create classpath containers for each referenced library.


5) How does the extension to the JSF Library registry help a tool adopter?
Gerry: JSF Tool or Component developers can provide plugins that will add their libraries as named collections to the JSF Library registry.


5a) Is it required for the JARs to be part of the plugin?
Gerry: No, a plugin can add references to JARs that are external to it. The extension provides a delegate mechanism that the tool adopter must implement which will return a collection of paths to JARs. This gives the developer flexibility to do whatever setup he may require (download from a website, perhaps). As long as the plugin can identify the jars on the local machine relative to the plugin, the JARs can be referenced in a library.

Closing remarks from Raghu Srinivasan

The current version of the source in the CVS is in a state that can be used to build the feature. We will post the first build of the product in a day or two. We invite the community to try the product and give feedback on the features.