Jump to: navigation, search

Difference between revisions of "STP Deployment Framework Requirements"

(References)
 
(One intermediate revision by the same user not shown)
Line 20: Line 20:
 
<li>Should not define any extra creation paths for a user  
 
<li>Should not define any extra creation paths for a user  
 
defining a new server in their workspace beyond providing extensions to existing  
 
defining a new server in their workspace beyond providing extensions to existing  
frameworks. <i>That is, no new framework code for creation paths. There are already frameworks in WTP/DTP for this purpose, and STP should leverage these directly.</i> [Proposed] [[User:Melder|Melder]]
+
frameworks. <i>That is, no new framework code for creation paths. There are already frameworks in WTP/DTP for this purpose, and STP should leverage these directly.</i> [Proposed] [[User:Melder|Melder]]</li>
</li>
+
  
 
<li>Should not define any new views for the monitoring of running applications
 
<li>Should not define any new views for the monitoring of running applications
Line 27: Line 26:
 
should leverage these directly. Creating new views for monitor servers will confuse
 
should leverage these directly. Creating new views for monitor servers will confuse
 
the user experience by exposing multiple ways to monitor different kinds of servers,
 
the user experience by exposing multiple ways to monitor different kinds of servers,
based on what the developers thought; not based on what the user expects.</i> [Proposed] [[User:Melder|Melder]]
+
based on what the developers thought; not based on what the user expects.</i> [Proposed] [[User:Melder|Melder]]</li>
</li>
+
  
 
<li>Should avoid defining any new concepts that are already satisfied by existing  
 
<li>Should avoid defining any new concepts that are already satisfied by existing  
 
frameworks. <i>The community should review the WTP Project Facets and understand
 
frameworks. <i>The community should review the WTP Project Facets and understand
how to integrate with this framework</i> [Proposed] [[User:Melder|Melder]]
+
how to integrate with this framework</i> [Proposed] [[User:Melder|Melder]]</li>
</li>
+
  
 
<li>Should avoid being overly complex, both for users and for developers extending any STP-defined framework. [Proposed] [[User:Melder|Melder]]</li>
 
<li>Should avoid being overly complex, both for users and for developers extending any STP-defined framework. [Proposed] [[User:Melder|Melder]]</li>
 
<li>Must have any packaging or deployment elements decoupled from the project structure. This means
 
that it will be possible to deploy an assembly from a single project, or many and that it will also
 
be possible to deploy multiple assemblies from a single project. It also means some flexibility
 
around the packaging [Proposed] (Oisin)</li>
 
 
<li>There should be no assumption that the target deploy environment is Java only [Proposed] (Oisin)</li>
 
 
<li>Scriptable - I think we need to be able to run this facility either in headless mode, or have Ant scripts generated or something like that. This will help automated set-up of environments, bringing new machines online as well as testing. [Proposed] (Oisin) </li>
 
 
<li> Good error reporting, meaning that we should be able to give meaningful error messages back
 
to the tool operator via the console at least if something goes wrong - there should also be some way to allow the target container to validate the deploy package too. [Proposed] (Oisin) </li>
 
 
<li> Should be able to do a relevant level of introspection on the target runtime if supported, so the
 
facility should be there to allow a pluggable conversation to be had between the deployment framework and the runtime [Proposed] (Oisin) </li>
 
 
<li>Must be able to plug in arbitrary archive format [Proposed] (Oisin) </li>
 
 
<li>
 
  
 
</ol>
 
</ol>
  
== References ==
+
== References ==
 
+
Some relevant commentary in the [http://wiki.eclipse.org/index.php/Web_Tools_Requirements_2.0#DTP Web Tools Requirements] list.
+
  
 
== Mailing List Discussions ==  
 
== Mailing List Discussions ==  

Latest revision as of 08:49, 1 May 2006

Growing and Vetting the Requirements

New requirements from committers should be added directly to the page with a reference to the author of the requirement and the text "[Proposed]". Each proposal should be vetted through the IRC meetings on Wednesday before it is changed from [Proposed] to [Accepted on date].

Requirements

  1. Should be able to contact a remote, running runtime instance. This means that you can do your deploy from your development host to a test/preprod host somewhere else. [Proposed] (Oisin)
  2. Should support the development of new connector instances to new runtimes. Now, just a clarification here: when I use the term 'support' then I do not mean 'allow' :) With 'allow' you can get it done by writing reams of code, with 'support' the framework makes it easy for you to focus on just the code you need to talk to your chosen runtime (note that this could be reams too, but you are at least writing in your area of expertise). [Proposed] (Oisin)
  3. Should not define any extra creation paths for a user defining a new server in their workspace beyond providing extensions to existing frameworks. That is, no new framework code for creation paths. There are already frameworks in WTP/DTP for this purpose, and STP should leverage these directly. [Proposed] Melder
  4. Should not define any new views for the monitoring of running applications on runtimes. There are already existing views in WTP/DTP for this purpose, and STP should leverage these directly. Creating new views for monitor servers will confuse the user experience by exposing multiple ways to monitor different kinds of servers, based on what the developers thought; not based on what the user expects. [Proposed] Melder
  5. Should avoid defining any new concepts that are already satisfied by existing frameworks. The community should review the WTP Project Facets and understand how to integrate with this framework [Proposed] Melder
  6. Should avoid being overly complex, both for users and for developers extending any STP-defined framework. [Proposed] Melder

References

Mailing List Discussions