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 "Touchpoint Use Cases"
| (3 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | This is a list of use cases that need to be considered when designing the [[Equinox/p2/Concepts | Touchpoint]] class. Some of these items are described in the context of the Eclipse Update Manager functionality. | |
| − | This is a list of use cases that need to be considered when designing the | + | |
| − | + | * Manage launch parameters through install handlers. This includes the management of a global property file and a user property file. The user property file is modified during the enable phase. For the multiuser case, it is easy to upgrade a user files during an enable/disable phase. It is not really possible to do this during the install by an admin. There has also been discussion that the enable handlers should be immutable (not depend a known state). | |
| − | + | * Manage JVM features. This had to be done slightly differently because JVM features have so many non-standard properties, We added and manage a plugin property file for these. While this has worked well for us it has a few thorns. There is a question of how to override the JVM properties from the command line or more generally how to combine JVM properties coming from this file and other places. When we attempt to integrate these features into the tooling we have the same questions. | |
| − | + | * Manage the branding. Done through the property files modified by install handlers. | |
| − | + | * Manage what gets launched. There may be multiple ICONS that represent different launch configurations. The ICON command length is limited so there needs to be an abstraction to handle this. | |
| − | + | * Manage the invocation of native exe's and bat and .sh. These are a problem because we usually lose the ability to track operations, log errors, etc. | |
| − | + | * Managing native service states through install handlers so that it can be upgraded/installed like any other feature/plugin. | |
===Other use cases=== | ===Other use cases=== | ||
| − | There is a need to be able to just unzip a platform and run. This likely implies that there is a need to do dynamic configuration on the first launch for a user. | + | * There is a need to be able to just unzip a platform and run. This likely implies that there is a need to do dynamic configuration on the first launch for a user. |
| − | For multiuser there is a need to be able to know if we are an admin installing into all the shared spaces or if we are just a user launching the platform. The actions performed are different. | + | * For multiuser there is a need to be able to know if we are an admin installing into all the shared spaces or if we are just a user launching the platform. The actions performed are different. |
| + | |||
| + | [[Category:Equinox p2|Touchpoint Use Cases]] | ||
Latest revision as of 14:18, 10 September 2008
This is a list of use cases that need to be considered when designing the Touchpoint class. Some of these items are described in the context of the Eclipse Update Manager functionality.
- Manage launch parameters through install handlers. This includes the management of a global property file and a user property file. The user property file is modified during the enable phase. For the multiuser case, it is easy to upgrade a user files during an enable/disable phase. It is not really possible to do this during the install by an admin. There has also been discussion that the enable handlers should be immutable (not depend a known state).
- Manage JVM features. This had to be done slightly differently because JVM features have so many non-standard properties, We added and manage a plugin property file for these. While this has worked well for us it has a few thorns. There is a question of how to override the JVM properties from the command line or more generally how to combine JVM properties coming from this file and other places. When we attempt to integrate these features into the tooling we have the same questions.
- Manage the branding. Done through the property files modified by install handlers.
- Manage what gets launched. There may be multiple ICONS that represent different launch configurations. The ICON command length is limited so there needs to be an abstraction to handle this.
- Manage the invocation of native exe's and bat and .sh. These are a problem because we usually lose the ability to track operations, log errors, etc.
- Managing native service states through install handlers so that it can be upgraded/installed like any other feature/plugin.
Other use cases
- There is a need to be able to just unzip a platform and run. This likely implies that there is a need to do dynamic configuration on the first launch for a user.
- For multiuser there is a need to be able to know if we are an admin installing into all the shared spaces or if we are just a user launching the platform. The actions performed are different.