Revision as of 18:41, 1 January 2008

Introduction

The Spaces project will provide an extensible framework and exemplary implementation for an Eclipse feature/plug-in set that streamlines the process of publishing, materializing and sharing a code base against a specified set of virtual services for source management, release staging and downloading, bug-tracking and community collaboration. The initial exemplary implementation will include an adapter to connect the framework to an extended version of AOL's virtual storage infrastructure (XDrive). Other exemplary implementations to capable and available virtual infrastructures will be included based on community demand and project resources (the project welcomes additional contributors to help with, e.g., an adapter to SourceForge).

Next steps

At the EclipseCon Spaces BOF we discussed some next steps. After BOF there were also some discussions in the hallway and at the bar. I thought it was a good idea to capture some of the things that where discussed.

Top Level Model

What is really an EclipseSpace? How are they named? Can an individual have only one or several spaces? What if several users wants to share a space, who is the owner? Can a space be handed over to someone else? etc. How is the space different from a component or project?

Naming

Clearly space names needs to be unique across space providers, so it seems natural that space names start with an identifier for the space provider. The space provider then has the responsibility to ensure that created spaces within their domain are unique. To keep the requirements simple the rest of the naming scheme and how a space can be shared, for a group, handed over etc. can be decided by the space provider. If however we want to create Eclipse user interfaces for management of access rights, etc. then there needs to be common APIs.

Spacenames should start with the space provider top URL (in reverse like for package names) for space services. As an example, this prefix could be "com.aol.spaces"

The space provider can then choose to have the space name be the same as the member name, or let members create multiple spaces. assuming the first is selected, the space name for member "fred" would be "com.aol.spaces.fred", or perhaps "com.aol.spaces/fred".

Naming inside the space

I think we also need a formal structure inside the space. At least for the top level structure where the user can keep one or several (?) update sites, one or several (?) CM repositories (possibly both CVS and SVN repositories). Our primary focus is Eclipse artifacts, so update sites works well, but for other technologies, maybe some other entry point for "downloads" is needed.

Once inside the CM repository the naming and structure depends on the technology used (java project, C project, etc.)

Space Services

The simplest service is just a "file respository" that allows sharing.

...to be continued...

Client Plugin

The first version of the client plug-in should satisfy these use-cases:

Use Case One

1. I start Eclipse (one that has the Spaces plug-in installed)
2. File > New > Project > Plug-in Development > Plug-in Project > "demo" ... Hello World ...
3. Right-click menu over project "demo" and choose Spaces > Publish Plug-in
4. 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.
5. 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.
6. 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.

Use Case Two

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 Plug-in.
   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 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.

Use Case Three

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 Plug-in.
   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.

Use Case Four

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 Plug-in.
   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 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 and one of the coolness feature on my AOL Eclipse Spaces.