development/miscdocuments/ServerToolsUseCases.html - gerrit/servertools/webtools.servertools.devsupport - Git at Google

 <!DOCTYPE html PUBLIC "-//w3c//dtd html 4.0 transitional//en">
 <html><head>
 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

 <link rel="stylesheet" href="http://www.eclipse.org/default_style.css" type="text/css">
 </head>


 <body alink="#ff0000" bgcolor="#ffffff" link="#0000ee" text="#000000" vlink="#551a8b">

 <table border="0" cellpadding="2" cellspacing="5" width="100%">

   <tbody><tr>

  		<TD WIDTH=60%>
 			<P ALIGN=LEFT><B><FONT SIZE=6><FONT FACE="Verdana, Arial, Helvetica, sans-serif">Server Tools Use Cases</FONT></FONT></B><BR><FONT SIZE=1><FONT FACE="Arial, Helvetica, sans-serif"><FONT COLOR="#8080ff">the
 			Server Tools Use Cases</FONT></FONT></FONT>
 						</P>
 		</TD>


 </td>

 <!--    <td width="19%" rowspan="2"><img src="images/Idea.jpg" height=86 width=120></td> -->

     <td rowspan="2" width="19%"><img src="http://www.eclipse.org/images/Idea.jpg" border="0" height="86" width="120"></td>

   </tr>


 </tbody></table>

 <table border="0" cellpadding="2" cellspacing="5" width="100%">

   <tbody><tr>

     <td colspan="2" align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">Principles</font></b></td>

   </tr>
 <tr>
 <td>
 <p>The purpose of this document is to list explicit use cases for the server tools component. These uses cases can be used to both help guide design (to make sure minimal API is sufficient to support these listed, and only these listed, use cases) and to help guide testing (both unit tests, and milestone/release testing).</p>
 			<P><B>Principle:</B> We'll consider starting point naive end users who
 			know nothing of servers, and they don't care, just want one installed
 			installed so they can focus on their web development. We'll consider
 			three levels: 1) User does near nothing, 2) user doesn't do much, but
 			may have to provide some configuration values and/or import
 			configuration values. 3) User has to provide many configuration
 			values, and in the worst cases, actually write ant scripts.</P>
 			<p><b>Principle:</b> In addition to "end user" use cases,
 we'll specify &quot;client code&quot; uses-case that may
 simply be specifying details of function needed for end-user use cases, but
 will always have a unit test associated with it. Also, we'll specify "service provider"
 use cases which can be used to define SPI's. </p>
 </td>
 </tr>
 <tr>
     <td colspan="2" align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">End User Use Cases</font></b></td>
   </tr>
   <tr>
   <td>
  <table width="95%" border="1" cellpadding="1" cellspacing="1">
 	<tbody>
 		<tr>
 			<th style="width: 108px">Name</th>
 			<th style="width: 60px">Priority</th>
 			<th style="width: 360px">Description</th>
 		</tr>
 		<tr>
 			<td>Install a Server</td>
 			<td>2</td>
 			<td>From an update site, user can install a
 			server (using Eclipse standard update manager functions).</td>
 		</tr>
 		<tr>
 			<td>Configure a Jakarta-tomcat</td>
 			<td>1</td>
 			<td>Given a Jakarta-tomcat server (V5) installed
 			on local file system, user can &quot;install&quot; a server to WTP by
 			selecting from a list of available server adapters, selecting the one
 			for Jakarta-tomcat server, and specifying location of server's
 			install directory.
 			<table border="1">
 				<tbody>
 					<tr>
 						<td>Variant 1</td>
 						<td style="width: 277px">JBoss Server instead</td>
 					</tr>
 				</tbody>
 			</table>
 			</td>
 		</tr>

 		<tr>
 			<td>Export ANT build scripts for modules</td>
 			<td>1</td>
 			<td>User exports ANT build script that compiles and packages a module in for use outside the Eclipse, possibly for automated builds. </td>
 		</tr>
 		<tr>
 			<td>Drag a module/artifact to a server to publish it</td>
 			<td>3</td>
 			<td>Users drags a module or a artifact in it into a server, which would mean the same action as &quot;Run on Server&quot; .</td>
 		</tr>

 		<tr>
 			<td>run on J2EE server</td>
 			<td>1</td>
 			<td>user can select a JSP and &quot;run on
 			server&quot;, meaning it will be displayed in Eclipse web browser.
 			<table border="1">
 				<tbody>
 					<tr>
 						<td style="width: 66px">Variant 1</td>
 						<td style="width: 348px">If no more than one installed, the user
 						will not get list to select from</td>
 					</tr>
 				</tbody>
 			</table>
 			<table border="1">
 				<tbody>
 					<tr>
 						<td style="width: 69px">Variant 2</td>
 						<td style="width: 345px">If none installed, the user will be given
 						a chance to select and install one (see Install a Server)</td>
 					</tr>
 				</tbody>
 			</table>
 			<table border="1">
 				<tbody>
 					<tr>
 						<td style="width: 65px">Variant 3</td>
 						<td style="width: 349px">If more than one installed, user given
 						the list</td>
 					</tr>
 				</tbody>
 			</table>
 			</td>
 		</tr>
 		<TR>
 			<TD>run on HTTP server</TD>
 			<TD></TD>
 			<TD>User can select an HTML file, and &quot;run on server&quot;. This use case can be performed with WST only. (This use case has not gotten a lot of discussion, but support for &quot;static projects&quot; is mentioned in WTP/WST vision statement, and is a good case to make sure the architecture and design is correct). </TD>
 		</TR>

 		<tr>
 			<td>Adapt to existing project/module layout<i>(I am not sure, this is may be a use case for project layout)</i></td>
 			<td>1</td>
 			<td>User describes the current project layout even if it is not a known layout of any kind. </td>
 		</tr>

 		<tr>
 			<td>Add runtime</td>
 			<td>1</td>
 			<td>Add a new server runtime environment that exists on the user's machine. (Pick runtime from list. Enter name, location. Enter runtime specific information.)</td>
 		</tr>

 		<tr>
 			<td>Edit or remove runtime</td>
 			<td>1</td>
 			<td>Modify runtime attributes or remove.</td>
 		</tr>

 		<tr>
 			<td>Target project</td>
 			<td>1</td>
 			<td>Target a project to a specific runtime. This is optional and a project may only be targetted to one runtime at a time. (Some project types do
                 not need a target, some projects do need a target)</td>
 		</tr>

 		<tr>
 			<td>Add server</td>
 			<td>1</td>
 			<td>Add (install) a new server. Enter name & hostname, pick a server type from a list, and enter server specific information. (Some server types may only support local, not remote. Some local servers may require a runtime.)</td>
 		</tr>

 		<tr>
 			<td>Edit or remove server</td>
 			<td>1</td>
 			<td>Modify server attributes or remove.</td>
 		</tr>

 		<tr>
 			<td>Start/Stop/Restart</td>
 			<td>1</td>
 			<td>Each server type may support some/all/none of these state changes. Each server type has an initial state (may be unknown), and must keep the state in sync once it is loaded.
                 Some of the state changes (start/stop) are not available unless the server is in the correct state. Console/Debug view, etc. should be sync'ed up or used as it makes sense
                 for the server type. Starting may be done in the regular Eclipse launch modes, e.g. Run, Debug, Profile, ... depending on what the server supports. Launch Configurations are
                 created and used as applicable.</td>
 		</tr>

 		<tr>
 			<td>Add project</td>
 			<td>1</td>
 			<td>Add a module to a server. User is presented with a list of modules that are available to be added to the server, as well as a list of modules from the workspace that are
                 already on the server. In some cases, the server may present additional modules in the second list that are not from the workspace/user. User can move modules around and
                 when they are done, the module is configured on (and possibly published to) the server.</td>
 		</tr>

 		<tr>
 			<td>Remove project</td>
 			<td>1</td>
 			<td>Same as above</td>
 		</tr>

 		<tr>
 			<td>Publish/Sync</td>
 			<td>1</td>
 			<td>One way publish of all modules to a particular server. Syncs the module content - could be a delta or a full refresh depending on the implementation.</td>
 		</tr>

 		<tr>
 			<td>Restart module</td>
 			<td>1</td>
 			<td>Optional based on server type support. Restart/refresh/remove cache for a particular module on the server to allow the newly published content to be served.</td>
 		</tr>

 		<tr>
 			<td>Change notification</td>
 			<td>1</td>
 			<td>User makes a change to a module (e.g. edit a file). User should be notified of the impact to any running servers and what they need to do to get the change
 			    propogated to the server. (e.g. nothing, republish, restart module, restart server) </td>
 		</tr>

 		<tr>
 			<td>Auto update</td>
 			<td>2</td>
 			<td>Automatically or via a single click, do the above use case to keep server in sync at all times.</td>
 		</tr>

 		<tr>
 			<td>Run/Debug/Profile on Server</td>
 			<td>1</td>
 			<td>From any artifact (UI selection, editor input, etc.), determine which module it belongs to, prompt to choose or create a server if necessary, publish/sync the module on the server, and display an
 			    appropriate client to access (run) that artifact on the server.</td>
 		</tr>

 <!--		<tr>
 			<td></td>
 			<td>1</td>
 			<td></td>
 		</tr>-->

 	</tbody>
 </table>
 </td></tr>

 <tr>
     <td colspan="2" align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">API Use Cases</font></b></td>
   </tr>


 <tr><td>
  <table width="95%" border="1" cellpadding="1" cellspacing="1">
 	<tbody>
 		<tr>
 			<th style="width: 108px">Name</th>
 			<th style="width: 60px">Priority</th>
 			<th style="width: 360px">Description</th>
 		</tr>

 		<tr>
 			<td>Create module type(s)</td>
 			<td>1</td>
 			<td>Define a new type of module (interface and id) so that other SPI providers can provide instances of these module or servers that support them.</td>
 		</tr>

 		<tr>
 			<td>Provide module factory</td>
 			<td>1</td>
 			<td>Define a new module factory for creating/discovering the modules of an existing type. (.modules file?)</td>
 		</tr>

 		<tr>
 			<td>Define runtime type</td>
 			<td>1</td>
 			<td>Define a new runtime type, along with the module types that it supports. Define what it means to target a project to this runtime.</td>
 		</tr>

 		<tr>
 			<td>Define server type</td>
 			<td>1</td>
 			<td>Define a new server type, along with the module types this it supports. Provide implementations for add/remove modules, publishing, start/stop, etc.</td>
 		</tr>

 		<tr>
 			<td>get list of server adapters</td>
 			<td>1</td>
 			<td>programmatically get list of known
 			Jakarta-tomcat servers adapters and their associated information
 			(name, version, whether installed or not, etc)</td>
 		</tr>
 		<tr>
 			<td>get list of installed servers</td>
 			<td>1</td>
 			<td>programmatically get list of installed
 			servers and their associated information (name, etc)</td>
 		</tr>
 		<tr>
 			<td>import/export server configuration</td>
 			<td>2</td>
 			<td>Can import or export server configuration
 			files, such as to give to another member of team. This file may best
 			be in XML format.</td>
 		</tr>
 		<tr>
 			<td>Server Providers can provide discoverable adapter</td>
 			<td>1 - SPI</td>
 			<td>The information needed to be listed as potential server adapter can be found completely in plugin.xml (not Java code, which would require activation of plugin). </td>
 		</tr>

 		<tr>
 			<td>Provide classloader behavior</td>
 			<td>1</td>
 			<td>A client, a jsp/ejb compiler for example, learns the classloader behavior to mimic the server runtime environment</td>
 		</tr>

 	</tbody>
 </table>
   </td>
 </tr>
 </tbody></table>


 </body></html>
	<!DOCTYPE html PUBLIC "-//w3c//dtd html 4.0 transitional//en">
	<html><head>
	<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

	<link rel="stylesheet" href="http://www.eclipse.org/default_style.css" type="text/css">
	</head>



	<body alink="#ff0000" bgcolor="#ffffff" link="#0000ee" text="#000000" vlink="#551a8b">

	<table border="0" cellpadding="2" cellspacing="5" width="100%">

	<tbody><tr>

	<TD WIDTH=60%>
	<P ALIGN=LEFT><B><FONT SIZE=6><FONT FACE="Verdana, Arial, Helvetica, sans-serif">Server Tools Use Cases</FONT></FONT></B><BR><FONT SIZE=1><FONT FACE="Arial, Helvetica, sans-serif"><FONT COLOR="#8080ff">the
	Server Tools Use Cases</FONT></FONT></FONT>
	</P>
	</TD>


	</td>

	<!-- <td width="19%" rowspan="2"><img src="images/Idea.jpg" height=86 width=120></td> -->

	<td rowspan="2" width="19%"><img src="http://www.eclipse.org/images/Idea.jpg" border="0" height="86" width="120"></td>

	</tr>


	</tbody></table>

	<table border="0" cellpadding="2" cellspacing="5" width="100%">

	<tbody><tr>

	<td colspan="2" align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">Principles</font></b></td>

	</tr>
	<tr>
	<td>
	<p>The purpose of this document is to list explicit use cases for the server tools component. These uses cases can be used to both help guide design (to make sure minimal API is sufficient to support these listed, and only these listed, use cases) and to help guide testing (both unit tests, and milestone/release testing).</p>
	<P><B>Principle:</B> We'll consider starting point naive end users who
	know nothing of servers, and they don't care, just want one installed
	installed so they can focus on their web development. We'll consider
	three levels: 1) User does near nothing, 2) user doesn't do much, but
	may have to provide some configuration values and/or import
	configuration values. 3) User has to provide many configuration
	values, and in the worst cases, actually write ant scripts.</P>
	<p><b>Principle:</b> In addition to "end user" use cases,
	we'll specify "client code" uses-case that may
	simply be specifying details of function needed for end-user use cases, but
	will always have a unit test associated with it. Also, we'll specify "service provider"
	use cases which can be used to define SPI's. </p>
	</td>
	</tr>
	<tr>
	<td colspan="2" align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">End User Use Cases</font></b></td>
	</tr>
	<tr>
	<td>
	<table width="95%" border="1" cellpadding="1" cellspacing="1">
	<tbody>
	<tr>
	<th style="width: 108px">Name</th>
	<th style="width: 60px">Priority</th>
	<th style="width: 360px">Description</th>
	</tr>
	<tr>
	<td>Install a Server</td>
	<td>2</td>
	<td>From an update site, user can install a
	server (using Eclipse standard update manager functions).</td>
	</tr>
	<tr>
	<td>Configure a Jakarta-tomcat</td>
	<td>1</td>
	<td>Given a Jakarta-tomcat server (V5) installed
	on local file system, user can "install" a server to WTP by
	selecting from a list of available server adapters, selecting the one
	for Jakarta-tomcat server, and specifying location of server's
	install directory.
	<table border="1">
	<tbody>
	<tr>
	<td>Variant 1</td>
	<td style="width: 277px">JBoss Server instead</td>
	</tr>
	</tbody>
	</table>
	</td>
	</tr>

	<tr>
	<td>Export ANT build scripts for modules</td>
	<td>1</td>
	<td>User exports ANT build script that compiles and packages a module in for use outside the Eclipse, possibly for automated builds. </td>
	</tr>
	<tr>
	<td>Drag a module/artifact to a server to publish it</td>
	<td>3</td>
	<td>Users drags a module or a artifact in it into a server, which would mean the same action as "Run on Server" .</td>
	</tr>

	<tr>
	<td>run on J2EE server</td>
	<td>1</td>
	<td>user can select a JSP and "run on
	server", meaning it will be displayed in Eclipse web browser.
	<table border="1">
	<tbody>
	<tr>
	<td style="width: 66px">Variant 1</td>
	<td style="width: 348px">If no more than one installed, the user
	will not get list to select from</td>
	</tr>
	</tbody>
	</table>
	<table border="1">
	<tbody>
	<tr>
	<td style="width: 69px">Variant 2</td>
	<td style="width: 345px">If none installed, the user will be given
	a chance to select and install one (see Install a Server)</td>
	</tr>
	</tbody>
	</table>
	<table border="1">
	<tbody>
	<tr>
	<td style="width: 65px">Variant 3</td>
	<td style="width: 349px">If more than one installed, user given
	the list</td>
	</tr>
	</tbody>
	</table>
	</td>
	</tr>
	<TR>
	<TD>run on HTTP server</TD>
	<TD></TD>
	<TD>User can select an HTML file, and "run on server". This use case can be performed with WST only. (This use case has not gotten a lot of discussion, but support for "static projects" is mentioned in WTP/WST vision statement, and is a good case to make sure the architecture and design is correct). </TD>
	</TR>

	<tr>
	<td>Adapt to existing project/module layout<i>(I am not sure, this is may be a use case for project layout)</i></td>
	<td>1</td>
	<td>User describes the current project layout even if it is not a known layout of any kind. </td>
	</tr>

	<tr>
	<td>Add runtime</td>
	<td>1</td>
	<td>Add a new server runtime environment that exists on the user's machine. (Pick runtime from list. Enter name, location. Enter runtime specific information.)</td>
	</tr>

	<tr>
	<td>Edit or remove runtime</td>
	<td>1</td>
	<td>Modify runtime attributes or remove.</td>
	</tr>

	<tr>
	<td>Target project</td>
	<td>1</td>
	<td>Target a project to a specific runtime. This is optional and a project may only be targetted to one runtime at a time. (Some project types do
	not need a target, some projects do need a target)</td>
	</tr>

	<tr>
	<td>Add server</td>
	<td>1</td>
	<td>Add (install) a new server. Enter name & hostname, pick a server type from a list, and enter server specific information. (Some server types may only support local, not remote. Some local servers may require a runtime.)</td>
	</tr>

	<tr>
	<td>Edit or remove server</td>
	<td>1</td>
	<td>Modify server attributes or remove.</td>
	</tr>

	<tr>
	<td>Start/Stop/Restart</td>
	<td>1</td>
	<td>Each server type may support some/all/none of these state changes. Each server type has an initial state (may be unknown), and must keep the state in sync once it is loaded.
	Some of the state changes (start/stop) are not available unless the server is in the correct state. Console/Debug view, etc. should be sync'ed up or used as it makes sense
	for the server type. Starting may be done in the regular Eclipse launch modes, e.g. Run, Debug, Profile, ... depending on what the server supports. Launch Configurations are
	created and used as applicable.</td>
	</tr>

	<tr>
	<td>Add project</td>
	<td>1</td>
	<td>Add a module to a server. User is presented with a list of modules that are available to be added to the server, as well as a list of modules from the workspace that are
	already on the server. In some cases, the server may present additional modules in the second list that are not from the workspace/user. User can move modules around and
	when they are done, the module is configured on (and possibly published to) the server.</td>
	</tr>

	<tr>
	<td>Remove project</td>
	<td>1</td>
	<td>Same as above</td>
	</tr>

	<tr>
	<td>Publish/Sync</td>
	<td>1</td>
	<td>One way publish of all modules to a particular server. Syncs the module content - could be a delta or a full refresh depending on the implementation.</td>
	</tr>

	<tr>
	<td>Restart module</td>
	<td>1</td>
	<td>Optional based on server type support. Restart/refresh/remove cache for a particular module on the server to allow the newly published content to be served.</td>
	</tr>

	<tr>
	<td>Change notification</td>
	<td>1</td>
	<td>User makes a change to a module (e.g. edit a file). User should be notified of the impact to any running servers and what they need to do to get the change
	propogated to the server. (e.g. nothing, republish, restart module, restart server) </td>
	</tr>

	<tr>
	<td>Auto update</td>
	<td>2</td>
	<td>Automatically or via a single click, do the above use case to keep server in sync at all times.</td>
	</tr>

	<tr>
	<td>Run/Debug/Profile on Server</td>
	<td>1</td>
	<td>From any artifact (UI selection, editor input, etc.), determine which module it belongs to, prompt to choose or create a server if necessary, publish/sync the module on the server, and display an
	appropriate client to access (run) that artifact on the server.</td>
	</tr>

	<!-- <tr>
	<td></td>
	<td>1</td>
	<td></td>
	</tr>-->

	</tbody>
	</table>
	</td></tr>

	<tr>
	<td colspan="2" align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">API Use Cases</font></b></td>
	</tr>


	<tr><td>
	<table width="95%" border="1" cellpadding="1" cellspacing="1">
	<tbody>
	<tr>
	<th style="width: 108px">Name</th>
	<th style="width: 60px">Priority</th>
	<th style="width: 360px">Description</th>
	</tr>

	<tr>
	<td>Create module type(s)</td>
	<td>1</td>
	<td>Define a new type of module (interface and id) so that other SPI providers can provide instances of these module or servers that support them.</td>
	</tr>

	<tr>
	<td>Provide module factory</td>
	<td>1</td>
	<td>Define a new module factory for creating/discovering the modules of an existing type. (.modules file?)</td>
	</tr>

	<tr>
	<td>Define runtime type</td>
	<td>1</td>
	<td>Define a new runtime type, along with the module types that it supports. Define what it means to target a project to this runtime.</td>
	</tr>

	<tr>
	<td>Define server type</td>
	<td>1</td>
	<td>Define a new server type, along with the module types this it supports. Provide implementations for add/remove modules, publishing, start/stop, etc.</td>
	</tr>

	<tr>
	<td>get list of server adapters</td>
	<td>1</td>
	<td>programmatically get list of known
	Jakarta-tomcat servers adapters and their associated information
	(name, version, whether installed or not, etc)</td>
	</tr>
	<tr>
	<td>get list of installed servers</td>
	<td>1</td>
	<td>programmatically get list of installed
	servers and their associated information (name, etc)</td>
	</tr>
	<tr>
	<td>import/export server configuration</td>
	<td>2</td>
	<td>Can import or export server configuration
	files, such as to give to another member of team. This file may best
	be in XML format.</td>
	</tr>
	<tr>
	<td>Server Providers can provide discoverable adapter</td>
	<td>1 - SPI</td>
	<td>The information needed to be listed as potential server adapter can be found completely in plugin.xml (not Java code, which would require activation of plugin). </td>
	</tr>

	<tr>
	<td>Provide classloader behavior</td>
	<td>1</td>
	<td>A client, a jsp/ejb compiler for example, learns the classloader behavior to mimic the server runtime environment</td>
	</tr>

	</tbody>
	</table>
	</td>
	</tr>
	</tbody></table>


	</body></html>