Jump to: navigation, search

Difference between revisions of "STP Deployment Framework Requirements"

(STP Deployment Framework Requirements)
 
Line 1: Line 1:
 +
== 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 <i>date</i>].
 +
 
== Requirements ==  
 
== Requirements ==  
  
Line 4: Line 8:
 
<li>Should be able to contact a remote, running runtime instance.  
 
<li>Should be able to contact a remote, running runtime instance.  
 
This means that you can do your deploy from your development  
 
This means that you can do your deploy from your development  
host to a test/preprod host somewhere else. (Oisin)</li>
+
host to a test/preprod host somewhere else. [Proposed] (Oisin)</li>
  
 
<li>Should support the development of new connector instances to new runtimes.  
 
<li>Should support the development of new connector instances to new runtimes.  
Line 12: Line 16:
 
easy for you to focus on just the code you need to talk to  
 
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
 
your chosen runtime (note that this could be reams too, but
you are at least writing in your area of expertise). (Oisin)</li>
+
you are at least writing in your area of expertise). [Proposed] (Oisin)</li>
  
 
<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> [[User:Melder|Melder]]</li>
+
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>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 22: 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> [[User:Melder|Melder]]</li>
+
based on what the developers thought; not based on what the user expects.</i> [Proposed] [[User:Melder|Melder]]</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> [[User:Melder|Melder]]</li>
+
how to integrate with this framework</i> [Proposed] [[User:Melder|Melder]]</li>
  
<li>Should avoid being overly complex, both for users and for developers extending any STP-defined framework. [[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>
  
 
</ol>
 
</ol>
 +
 +
== References == 
 +
 +
== Mailing List Discussions ==
 +
 +
<ul>
 +
  <li>[http://dev.eclipse.org/mhonarc/lists/stp-dev/msg00209.html WTP/DTP division of labor for STP] <i>Oisin Hurley</i></li>
 +
 +
  <li>[http://dev.eclipse.org/mhonarc/lists/stp-dev/msg00194.html Seeking a balance] <i>Michael D. Elder</i></li>
 +
 +
  <li>[http://dev.eclipse.org/mhonarc/lists/stp-dev/msg00186.html Re: IRC record 19apr06] <i>John O'Shea</i></li>
 +
</ul>

Revision as of 07:45, 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