Skip to main content

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.

Jump to: navigation, search

Adding an Additional Runtime

Overview

In most cases the STP as distributed will not be sufficient for the requirements of the user. They will most likely have a differnt SOA environment than that which STP will support by default. The purpose of this scenario is to describe this process.

Assumptions

Scenario Walk Through

  • After downloading and installing the STP users will need to configure a new runtime environment.

Now we have two possible options here, either the STP provides enough user configuration items that allows runtimes to be slotted in via user config or the tooling supplier for the SOA runtime provide additional plug-ins to configure the STP to run with this environment. I feel that it should be the later so that we should focus on providing a well defined set of areas that allows tool developers leverage the capabilities of the STP via extension points. So this scenario could work as follows:

  • The user will then proceed to install the plug-ins from the new SOA runtime either using an update site or by extracting the plug-ins into the eclipse installation.
  • The plug-in will customise the getting started wizards (likely to be New Project Wizards) and offer out their own specific project types.
  • The types of files supported can also be extended.
  • Existing file types can have new default editors associated with them, e.g. instead of the WSDL editor that is present by default in the STP a new one can be provided. Or existing editors could be extended, in terms of WSDL, tools could extend how the user manipulates the Physical WSDL contract.
  • Generators which create additional the runtime artefact's will also need to be registered so that the user will follow an identical flow to the default STP behavior. The major different will be the screens to interface to the generator will be different, corresponding to the requirements of the new SOA environment's generator.
  • Finally deployment will be identical but the choices available for deployment will be based on the new SOA Runtimes environment choices. The tooling for this will need to leverage the deployment component shipped with the STP.

Back to the top