jsf/dev_status/2005-12-05.xml - www.eclipse.org/webtools - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <?xml-stylesheet type="text/xsl" href="../../wtp.xsl"?>
 <html>
 	<head>
 		<meta name="root" content="../../.." />
 		<title>the javaserver faces tools subproject</title>
 	</head>
 	<body>

 		<h1>jsf</h1>
 		<h2>Meeting Notes: 2005-12-05.</h2>
 		<h3>Agenda</h3>
 		<ul>
 			<li>Demo Milestone 1 Features</li>
 			<li>Questions and Answers</li>
 		</ul>
 		<h3>Meeting Notes</h3>
 		<h4>Attendees</h4>
 		<ul>
 			<li>Raghu Srinivasan[RS]</li>
 			<li>Ian Trimble[IT]</li>
 			<li>Gerry Kessler[GK]</li>
 			<li>Justin Chen[JU]</li>
 			<li>Marshall Culpepper[JC]</li>
 			<li>Eric Norman</li>
 			<li>Sergei Pogrebny</li>
 			<li>Bob Gallagher[BG]</li>
 			<li>Jeffrey Liu[JL]</li>
 			<li>John Rohrlich</li>
 			<li>George DiCandio</li>
 			<li>David Williams</li>
 			<li>Nitin Dahyabhai</li>
 			<li>Lawrence Mandel</li>
 		</ul>
 		<h4>Regrets</h4>
 		<ul>
 			<li></li>
 		</ul>
 		<h2>Introduction from Raghu Srinivasan</h2>
 		<p>
 			The two main objectives of the Milestone 1 release are the
 			following:
 			<ul>
 				<li>
 					Build the basic infrastructure required to develop a
 					simple JSF application
 				</li>
 				<li>
 					Follow the Eclipse development processes and set up
 					the necessary support to help in contributing to
 					Eclipse.
 				</li>
 			</ul>
 			<br></br>
 			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.
 			<br></br>
 			Gerry Kessler and Ian Trimble are the key contributors on
 			this project.
 		</p>
 		<h2>Demo by Gerry Kessler</h2>
 		<p>
 			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:
 			<ul>
 				<li>Add required jars to the projects classpath.</li>
 				<li>
 					Configure ‘web.xml’ with the JavaServer Faces Sevlet
 					and define the servlet mapping.
 				</li>
 				<li>
 					Create a stub application configuration file
 					(faces-config.xml)
 				</li>
 				<li>Run a JSF JSP page on the target server.</li>
 			</ul>
 			Features demonstrated
 			<ul>
 				<li>JSF Project Intall and Uninstall Facets</li>
 				<li>JSF Library Registry</li>
 				<li>Run JSF JSP file on server</li>
 				<li>
 					Extension plugin to add a library to the JSF Library
 					Registry.
 				</li>
 			</ul>
 		</p>
 		<h2>Questions and Answers</h2>
 		<p>
 			<b>
 				1) What are the issues in defining a class path
 				container for each of the library in the registry?
 			</b>
 			<br></br>
 			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.
 			<br></br>
 			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.
 			<br></br>
 			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.
 		</p>
 		<p>
 			<b>
 				2) Can a JSF Facet be added to an existing non-JSF
 				Project?
 			</b>
 			<br></br>
 			Gerry: Yes, through the Project Facets section of the
 			Properties page for the Web project.
 		</p>
 		<p>
 			<b>
 				3) What are the proper actions that should be taken when
 				the JSF Project Facet is removed from a project?
 			</b>
 			<br></br>
 			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.).
 		</p>
 		<p>
 			<b>
 				4) What is the difference between the class path
 				container that you would like to implement and the Web
 				Application Library?
 			</b>
 			<br></br>
 			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.
 		</p>
 		<p>
 			<b>
 				5) How does the extension to the JSF Library registry
 				help a tool adopter?
 			</b>
 			<br></br>
 			Gerry: JSF Tool or Component developers can provide plugins
 			that will add their libraries as named collections to the
 			JSF Library registry.
 		</p>
 		<p>
 			<b>
 				5a) Is it required for the JARs to be part of the
 				plugin?
 				<br></br>
 			</b>
 			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.
 		</p>

 		<h2>Closing remarks from Raghu Srinivasan</h2>
 		<p>
 			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.
 			<b>
 				We invite the community to try the product and give
 				feedback on the features.
 			</b>
 		</p>

 	</body>
 </html>
	<?xml version="1.0" encoding="UTF-8"?>
	<?xml-stylesheet type="text/xsl" href="../../wtp.xsl"?>
	<html>
	<head>
	<meta name="root" content="../../.." />
	<title>the javaserver faces tools subproject</title>
	</head>
	<body>

	<h1>jsf</h1>
	<h2>Meeting Notes: 2005-12-05.</h2>
	<h3>Agenda</h3>
	<ul>
	<li>Demo Milestone 1 Features</li>
	<li>Questions and Answers</li>
	</ul>
	<h3>Meeting Notes</h3>
	<h4>Attendees</h4>
	<ul>
	<li>Raghu Srinivasan[RS]</li>
	<li>Ian Trimble[IT]</li>
	<li>Gerry Kessler[GK]</li>
	<li>Justin Chen[JU]</li>
	<li>Marshall Culpepper[JC]</li>
	<li>Eric Norman</li>
	<li>Sergei Pogrebny</li>
	<li>Bob Gallagher[BG]</li>
	<li>Jeffrey Liu[JL]</li>
	<li>John Rohrlich</li>
	<li>George DiCandio</li>
	<li>David Williams</li>
	<li>Nitin Dahyabhai</li>
	<li>Lawrence Mandel</li>
	</ul>
	<h4>Regrets</h4>
	<ul>
	<li></li>
	</ul>
	<h2>Introduction from Raghu Srinivasan</h2>
	<p>
	The two main objectives of the Milestone 1 release are the
	following:
	<ul>
	<li>
	Build the basic infrastructure required to develop a
	simple JSF application
	</li>
	<li>
	Follow the Eclipse development processes and set up
	the necessary support to help in contributing to
	Eclipse.
	</li>
	</ul>
	<br></br>
	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.
	<br></br>
	Gerry Kessler and Ian Trimble are the key contributors on
	this project.
	</p>
	<h2>Demo by Gerry Kessler</h2>
	<p>
	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:
	<ul>
	<li>Add required jars to the projects classpath.</li>
	<li>
	Configure ‘web.xml’ with the JavaServer Faces Sevlet
	and define the servlet mapping.
	</li>
	<li>
	Create a stub application configuration file
	(faces-config.xml)
	</li>
	<li>Run a JSF JSP page on the target server.</li>
	</ul>
	Features demonstrated
	<ul>
	<li>JSF Project Intall and Uninstall Facets</li>
	<li>JSF Library Registry</li>
	<li>Run JSF JSP file on server</li>
	<li>
	Extension plugin to add a library to the JSF Library
	Registry.
	</li>
	</ul>
	</p>
	<h2>Questions and Answers</h2>
	<p>
	<b>
	1) What are the issues in defining a class path
	container for each of the library in the registry?
	</b>
	<br></br>
	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.
	<br></br>
	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.
	<br></br>
	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.
	</p>
	<p>
	<b>
	2) Can a JSF Facet be added to an existing non-JSF
	Project?
	</b>
	<br></br>
	Gerry: Yes, through the Project Facets section of the
	Properties page for the Web project.
	</p>
	<p>
	<b>
	3) What are the proper actions that should be taken when
	the JSF Project Facet is removed from a project?
	</b>
	<br></br>
	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.).
	</p>
	<p>
	<b>
	4) What is the difference between the class path
	container that you would like to implement and the Web
	Application Library?
	</b>
	<br></br>
	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.
	</p>
	<p>
	<b>
	5) How does the extension to the JSF Library registry
	help a tool adopter?
	</b>
	<br></br>
	Gerry: JSF Tool or Component developers can provide plugins
	that will add their libraries as named collections to the
	JSF Library registry.
	</p>
	<p>
	<b>
	5a) Is it required for the JARs to be part of the
	plugin?
	<br></br>
	</b>
	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.
	</p>

	<h2>Closing remarks from Raghu Srinivasan</h2>
	<p>
	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.
	<b>
	We invite the community to try the product and give
	feedback on the features.
	</b>
	</p>

	</body>
	</html>