STP Deployment Framework Requirements

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
7. 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)
8. There should be no assumption that the target deploy environment is Java only [Proposed] (Oisin)
9. 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)
10. 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)
11. 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)
12. Must be able to plug in arbitrary archive format [Proposed] (Oisin)

References

Some relevant commentary in the Web Tools Requirements http://wiki.eclipse.org/index.php/Web_Tools_Requirements_2.0#DTP list.

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