Spaces/Use Cases

Use Case One: Initial Publish

1. File > New > Project > Plug-in Development > Plug-in Project > "demo" ... Hello World ...
2. Right-click menu over project "demo" and choose Spaces > Publish...
3. A wizard/dialog box opens to ask me a few questions including:
   1. Which spaces adapter to use. I will choose "AOL Eclipse Spaces" for this example.
   2. Because this is the first time I have used AOL Eclipse Spaces in this instance of Eclipse, I am asked for my login and password. These are stored in the Eclipse workspace so that I don't have to enter them in the future.
4. The Spaces plug-in does a client side build and then uploads the results to the storage server:
   1. Compile all the java code (usually already compiled via incremental compiler)
   2. Jar-up the class files.
   3. Jar into a plug-in jar with correct manifest file, etc.
   4. Create a feature.xml for this one plug-in. Saves the feature.xml along with the plugin.xml so that it can be re-used. (The Spaces plug-in either asks for the necessary information via the wizard, or it assumes some defaults, or it generates some defaults from the plug-in code.)
   5. Jar into a feature jar with correct manifest file, etc.
   6. Download the site.xml from my AOL Eclipse Spaces update site. If there is no site.xml, generate a new empty site.xml locally.
   7. Add this new feature to the local site.xml
   8. Upload the new site.xml, feature jar, and plugin jar to my AOL Eclipse Spaces update site.
5. When the publish action is complete, the wizard shows me the public url to my update site.
   1. My friends and I can go to my AOL Eclipse Spaces update site using the Eclipse Update Manager (based on my AOL XDrive permissions) and download and install my "demo" plug-in.

implementation

• Step 3 starts with Spaces.getSpaceProviderItems() and shows the ISpaceProviderHandle.getName() and .getDescription() to the user so that he/she can choose one. ??
• Once he/she chooses one, it uses ISpaceProviderHandle.getSpaceProvider() to get the provider object.
• Then what??

Henrik - regarding step 3:

• Actually, step 3 should start with "select space" from already available spaces, but since this use case describes initial use, there are no spaces added to the workspace, so user should select a provider first.
• Service provider specific wizards can be added as extensions to the plugin "com.eclipse.spaces.ui" - it has an "addSpaceWizard" point right now, but this is placeholder right now.
  • The addspace wizard extension point is used to add a wizard for a "providerScheme" - the "providerScheme" for AOL would be what they choose to use for their URIs (probably "xdrive").
• The generic spaces.ui should use "ISpaceProviderHandle.getProviderScheme()" to get the key to locate the wizard to use for adding a space.
• If no wizard was registered for the scheme - then a generic wizard should be displayed. This wizard asks for the URI of the space to add - (similar to how you add a CVS or SVN repository). The user does not have to enter the ":spaces:providerScheme" part or the URI, as that is already known from the selected provider. It can however not help with any additional fields in the URI, nor signup - that is the reason why a provider may want to add their own wizard, as that wizard can either handle sign-up from within the wizard, or refer the user to a web page where they should sign up, as well as handling provider specific parts of the URI.
• With this design, a space provider that requires password:
  • must add an extension point to their headless space provider plugin - if there is an extension it is used to obtain needed password, if it is not extended, the provider would either get the password from the keyring or throw an exception.
  • In the space provider's ui plugin, the provider implements a dialog for user/password (or we write a generic plugin for this that can be reused).
  • Optionally implement the addspace wizard if provider wants the user to be able to enter the password when adding the space. Alternatively, we expand the generic wizard to also asks for login/password and store that in the eclipse key ring for the URI.
• Similar to the CVS/SVN, the connection to the space can be tested before adding the space to the SpaceCatalog.
• The space is added to the space catalog using "SpaceCatalog.addSpaceAddress(URI address)"

Henrik - regarding step 4&5:

As it is possible to publish different things in different ways, this is what the user does:

• One of:
  • Start the "Space Publishing Wizard" - the first question is "what do you want to publish" - user presses Browse and browses for the resource to publish.
  • Select the Resource in the navigator and do a right mouse click - in the context menu there is an action "Publish in a Space". This leads to the same "Space Publishing Wizard", but it can then skip the first page as the resource is already selected.
• Select the space to publish to
  • Done by getting available spaces from "SpaceCatalog.getSpaceAddresses()" - right now there is no better "name" associated with a catalog entry - this should be added to space catalog.
• Select how to publish the selected resource - a list of possible ways is presented to the user, the user selects one.
  • Done by:
    • Getting the ISpace for the address "Spaces.getSpace(address)"
    • Calling Spaces.getApplicablePublishingOperations(IResource theSelectedResource, ISpace theSelectedSpace)
    • Get a list of IPublishingOperation back - this list is displayed
    • The user picks one operation (selectedPublishingOperation)
• Start a wizard to handle details for the publishing operation
  • The org.eclipse.spaces.ui plugin has an extension point for publishing operation wizards (undefined how to get it, but suggest from "SpacesUI.getPublishingOperationWizard(selectedPublishingOperation)"
• The wizard takes user through the specific steps for the publisher - options etc.
  • The wizard steps change properties in the "selectedPublishingOperation" until done
  • To execute job call "selectedPublishingOperation.getJob()" and schedule it as any other Eclipse Job
    • (The implementation handles locking so publishing jobs do not step on each other)
    • The job will do whatever it needs - make sure things are compiled, copy results into the EFS provided by a space provider etc.)
• A publisher that has "URLs to share" - for instance for an "update site" will present this on its last page. (It is possible to do more with this later - perhaps looking up the URL's even after publishing is done in case user forgot - for update sites, the formula of getting to the update site from a root URL to the space is given, but for other types of publishing it may not be that easy. Not needed now, but there is information in the space metadata (inside the space) that can be displayed).
• publishing is done

Use Case Two: Incremental Publish

1. I modify the "demo" plug-in project to do something more interesting.
2. Right-click menu on the "demo" project to do Spaces > Publish...
   1. Because I've already published it to my AOL Eclipse Spaces and because I've already logged-in in this Eclipse instance, it just compiles, builds, and uploads the result.
   2. Because I did not change the version number in the plug-in, this new copy of the "demo" feature overwrites the existing feature on the update site.
3. When the publish action is complete, the wizard shows me the public url to my update site. It is the same public url as it was for use case one.

Use Case Three: Publish New Version

1. I modify the "demo" plug-in project yet again, this time to fix a bug.
   1. I update the version number in the plugin.xml from 0.1 to 0.2
2. Right-click menu on the "demo" project to do Spaces > Publish...
   1. Because I've already published it to my AOL Eclipse Spaces and because I've already logged in in this Eclipse instances, it just compiles, builds, and uploads the result.
   2. Because I changed the version number in the plug-in, this new copy of the "demo" feature will be added to site.xml and now there will be two versions of the demo feature on my AOL Eclipse Spaces.
3. When the publish action is complete, the wizard shows me the public url to my update site. It is the same public url as it was for use case one.

Use Case Four: Publish a Second Plug-in

1. I use File > New > Project > Plug-in Project ... to make a new "coolness" plug-in.
2. Right-click menu on the "coolness" project to do Spaces > Publish...
3. A wizard/dialog box opens to ask me a few questions including:
   1. Which spaces adapter to use. I will choose "AOL Eclipse Spaces" for this example.
   2. Because I've already logged-in to AOL Eclipse Spaces in this Eclipse instance, it just compiles, builds, and uploads the result.
   3. Because this is a new plug-in/feature, this new "coolness" feature will added to site.xml and now there will be two versions of the "demo" feature (use cases 1 and 2) and one of the "coolness" feature on my AOL Eclipse Spaces.
4. When the publish action is complete, the wizard shows me the public url to my update site. It is the same public url as it was for use case one.

Use Case Five: Withdraw

1. I decide to withdraw the "coolness" plug-in at my AOL Eclipse Spaces.
2. Right-click menu on the "coolness" project to do Spaces > Disconnect...
3. A dialog asks me if I am sure
4. Then it removes all instances of the "coolness" project from my AOL Eclipse Spaces update site.
   1. If I had done a Spaces > Share... or Spaces > Promote... or any of the other Spaces actions, the Spaces > Disconnect... would also clean up those actions.
   2. Additionally, if I go to do a Spaces > Publish... on the "coolness" project in the future, I will be prompted again for which spaces provider to publish to.

Use Case Six: Repair

1. I use the normal AOL Xdrive interface to manipulate the files on my Xdrive. I delete the older versions of the "demo" plug-in.
   1. This messes up the update site, of course, but I can fix it by publishing again:
2. Right-click menu on the "demo" project to do Spaces > Publish...
   1. Because I've already published it to my AOL Eclipse Spaces and because I've already logged-in in this Eclipse instance, it just compiles, builds, and uploads the result.
   2. Because I did not change the version number in the plug-in, this new copy of the "demo" feature overwrites the existing feature on the update site.
   3. Also the update site is rebuilt and the older versions of the "demo" feature are removed from the site.xml file.
3. When the publish action is complete, the wizard shows me the public url to my update site. It is the same public url as it was for use case one.

Use Case Seven: Initial Share of Published Project

1. I decide to share the source code to the "demo" plug-in at my AOL Eclipse Spaces.
2. Right-click menu on the "demo" project to do Spaces > Share...
3. Sets up a CVS or SVN (depends on the spaces provider) connection to my AOL Eclipse Spaces.
   1. Sets the CVS/SVN module name to "demo".
4. Switches me to the Team Synchronize perspective where I can complete the source code commit.

Use Case Eight: Describe URLs

1. I want to share my source code with a colleague, but I don't remember how to connect to the repository.
2. Right-click menu on the "demo" project to do Spaces > URLs...
3. Opens a dialog box that displays the public urls/uris to all of the spaces bits about this project. The url to the update site that I have Spaces > Publish...ed; the url to the CVS/SVN repository that I have Spaces > Share...ed; etc.

Use Case Nine: Initial Share of New Project

1. I use File > New > Project > Plug-in Project ... to make a new "nifty" plug-in.
2. Right-click menu on the "nifty" project to do Spaces > Share...
3. A wizard/dialog box opens to ask me a few questions including:
   1. Which spaces adapter to use. I will choose "AOL Eclipse Spaces" for this example.
   2. Because I've already logged-in to AOL Eclipse Spaces in this Eclipse instance, it proceeds to:
4. Sets up a CVS or SVN (depends on the spaces provider) connection to my AOL Eclipse Spaces.
   1. Sets the CVS/SVN module name to "nifty".
5. Switches me to the Team Synchronize perspective where I can complete the source code commit.

Use Case Ten: Subsequent Share

1. I modify the "nifty" project with some nifty new features.
2. Right-click menu on the "nifty" project do do Spaces > Share...
3. Because I've already set up the share of this project to my AOL Eclipse Spaces repository, it takes me directory to:
4. Switches me to the Team Synchronize perspective where I can complete the source code commit.