Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "STP Deployment Framework Requirements"
(STP Deployment Framework Requirements) |
|||
| (One intermediate revision by the same user not shown) | |||
| 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> | ||
Latest revision as of 08:49, 1 May 2006
Contents
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
- 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)
- 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)
- 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
- 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
- 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
- Should avoid being overly complex, both for users and for developers extending any STP-defined framework. [Proposed] Melder
References
Mailing List Discussions
- WTP/DTP division of labor for STP Oisin Hurley
- Seeking a balance Michael D. Elder
- Re: IRC record 19apr06 John O'Shea