Spaces/Architecture/appspecs

Spaces View

The spaces view is comparable to the team repository view.

Must have requirements:

• At the top there is a toolbar with commands
  • refresh
  • collapse all
  • add space
• Below there is a tree view organized as follows:
  • no root folder
  • top level folders are Space Providers for which there are accounts and spaces
  • next level folders are accounts
  • third level folders are spaces

Should have:

• toolbar commands:
  • refresh
  • collapse all

Nice to have:

• toolbar buttons for "go into" and "go back" to limit the view to the selected section (like SVN view).
• options to organize the list differently (hide provider, and account), order by name, etc.

Context menus

• For Service Provider node
  • View information - displays information about the provider, capabilities, and presents links to more information
• For Account node
  • Properties - displays and allows change of account properties (address, login, password, etc.)
• For Space Resource node
  • Properties - address to the space etc.

Add Space Wizard

This wizard is used to add a Space Reference. This wizard is typically invoked from the Spaces View.

Here is an outline of the steps:
1. Select a Service Provider. A list of available service providers is listed. As the user selects one, information about this provider is displayed on the wizard page.

2. Select Account. If accounts have already been defined for the service provider they are presented in a list. If there are no accounts, and the space provider does not support account creation information is displayed that the service provider needs to be contacted though other means (that service provider did not supply). If service provider supports account creation, the user can press a button and complete this as an alternative to entering account information for an existing account.

3. Enter Space Reference. User enters a reference to a space for the account. Alternatively, if the space provider supports creation of spaces for an account, the user can take an alternate route that creates a new space.

• Should probably have a capability flag indicating if account and space are synonyms, or if mulitple spaces per account can be created - then this step can be automated.
• An API for enumerating spaces for an account would be nice to have here.

4. (Processing) The information about the account, and the space are added to the corresponding catalogs. If source service is available, the source respository is added to the set of repositories.

5. (If source service is available) Check out Projects. The user is asked if the project(s) in the space source repository should be checked out into the workspace. If so, there may be additional steps that the user needs to take (may be implemented by running the import wizard multiple times perhaps) - the best would be if this could be fully automated.

6. (If there are collborations available) 'Hook up Collaborations. The user is asked if the collaborations defined for the space should be hooked up. A simple implementation has just one question and hooks up all. A better solution lists them, and lets the user select which collaborations should be hooked up.

7. (Processing) Events are fired to allow additional decoupled services to do their work.

Notes:

• If wizard is invoked as a context operation on a service provider, or on an account, the wizard can start on the appropriate step (2 or 3) with provider and account already selected.
• There should be functionality to later rerun "check out project" and "hook up collaborations" if this was not done when adding the space.
• It would perhaps be nice to allow addition of references even if the space is not available. The hookup would then occur when the space becomes available.

Publish Wizard

Publishing is performed by the user by pointing to the artifact (file or folder) to publish, and the starting the Spaces Publishing Wizard. The wizard does the following:

• The user selects a space (or takes alternate route via creating account and creating space first)
• If user published a plug-in, user enters options for "publish as" - the set of available ways to publish may be hardwired in an initial implementation (see note below)
  • Should an OBR be created or an existing OBR be used, or perhaps no OBR?
  • Should an Eclipse feature be created or an existing feature be used, or perhaps no feature?
  • Should an Eclipse update site be created or an existing update site be used (both implies a feature), or no update site?
  • Should an Eclipse p2 profile be created or an existing p2 profile be used, or no p2 profile?
• If user published something that is not a plug-in:
  • What kind of meta-data should be provided (name, version, type)
  • Documentation
  • Short description
  • Or appoint known meta-data format (cspec, POM, etc.)
• A selection if the published material is for "test" or "production" (the implementation of the space publisher defines how this is mapped to the underlying technology).

Notes:

• A first implementation can have a small set of hardwired ways of publishing, but this should be an extension point in the future. The Wizard UI then gets slightly more complex as the different "publish as" may have their own options that needs to be specified by the user, etc. A mechanism should query if an available "publish as" is applicable to the resource selected for publishing when presenting the list of possible publishing formats.
• The available formats should also have a flag indicating if they require the SubFolder capability of the space and the list should be pruned based on this. (e.g. a space that only allows publishing of top level files can not function as an Eclipse Update site).