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??

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.