| <!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> |